Battery failure prediction

ABSTRACT

A method includes obtaining battery characterization data based on sensor data from one or more sensors onboard a vehicle. The method includes providing the battery characterization data as input to a trained model to generate a model output. The methos further includes altering a vehicle operating parameter based on the model output.

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims priority to and is a continuation of U.S.patent application Ser. No. 17/663,326 entitled “BATTERY FAILUREPREDICTION,” filed May 13, 2022, which claims priority to and is acontinuation of U.S. patent application Ser. No. 17/392,744 entitled“BATTERY FAILURE PREDICTION,” filed Aug. 3, 2021 (now issued as U.S.Pat. No. 11,333,712), which claims priority to U.S. ProvisionalApplication No. 63/071,663 filed Aug. 28, 2020, entitled “BATTERYFAILURE PREDICTION,” which is incorporated by reference herein in itsentirety.

BACKGROUND

Batteries are an important though sometimes taken-for-granted aspect ofmodern technology. Several factors have increased the importance ofbatteries. For example, battery technology is considered anenvironmentally friendly alternative to fossil fuel technology,especially in the areas of vehicle propulsion and utility grids. Asanother example, electronic devices are becoming smaller and moremobile, while consumers continue to expect high performance andconnectivity from such devices as they operate on batteries.

SUMMARY

Techniques for predicting battery failure are described. Various aspectsare described herein with respect to “batteries,” “battery packs,” or“battery cells” (also referred to as “cells”). As used herein, a batterymay be a single-cell battery or a multi-cell battery. A cell maygenerally refer to a combination structure that includes, for example, apair of electrodes (e.g., anode and cathode) and an electrolyte. Abattery that has multiple cells may also be referred to as a batterypack.

In accordance with an aspect of the present disclosure, a methodincludes obtaining, by a processor, driver characterization data basedon sensor data from one or more sensors onboard a vehicle. The sensordata is captured during a time period that includes multiple dischargingoperations and multiple recharging operations of a battery pack of thevehicle. The method also includes providing, by the processor, thedriver characterization data as input to a trained model to generate amodel output and estimating, by the processor, a battery failuretimeline for the battery pack based on the model output.

In accordance with another aspect, a system includes one or moreprocessors and one or more memory devices coupled to the one or moreprocessors. The one or more memory devices store instructions that areexecutable to cause the one or more processors to perform operationsincluding obtaining driver characterization data based on sensor datafrom one or more sensors onboard a vehicle. The sensor data is capturedduring a time period of that includes multiple discharging operationsand multiple recharging operations of a battery pack of the vehicle. Theoperations also include providing the driver characterization data asinput to a trained model to generate a model output and estimating abattery failure timeline for the battery pack based on the model output.

In yet another aspect, a computer-readable storage device storesinstructions that are executable by a processor to cause the processorto perform operations including obtaining driver characterization databased on sensor data from one or more sensors onboard a vehicle. Thesensor data is captured during a time period of that includes multipledischarging operations and multiple recharging operations of a batterypack of the vehicle. The operations also include providing the drivercharacterization data as input to a trained model to generate a modeloutput and estimating a battery failure timeline for the battery packbased on the model output.

In still another aspect, a system includes means for obtaining drivercharacterization data based on sensor data from one or more sensorsonboard a vehicle. The sensor data is captured during a time period ofthat includes multiple discharging operations and multiple rechargingoperations of a battery pack of the vehicle. The system also includesmeans for estimating a battery failure timeline for the battery pack byproviding the driver characterization data as input to a trained modelto generate a model output indicative of the battery failure timeline.

In accordance with an aspect of the present disclosure, a methodincludes obtaining, for each cell of a set of cells of a battery pack,cell condition data. The cell condition data for a particular cellindicates a sensed condition of the particular cell. The method alsoincludes evaluating, by a processor, cell condition data and batterypack configuration data to identify a potential battery failuremechanism for the battery pack. The battery pack configuration dataincludes one or more of physical connections within the battery pack,physical connections of the battery pack to a support structure of avehicle, electrical connections within the battery pack, or electricalconnections of the battery pack to vehicle systems. The method alsoincludes generating an output indicative of the potential batteryfailure mechanism.

In accordance with another aspect, a system includes one or moreprocessors and one or more memory devices coupled to the one or moreprocessors. The one or more memory devices store instructions that areexecutable to cause the one or more processors to perform operationsincluding obtaining cell condition data for each cell of a set of cellsof a battery pack. The cell condition data for a particular cellindicates a sensed condition of the particular cell. The operations alsoinclude evaluating the cell condition data and battery packconfiguration data to identify a potential battery failure mechanism forthe battery pack. The battery pack configuration data includes one ormore of physical connections within the battery pack, physicalconnections of the battery pack to a support structure of a vehicle,electrical connections within the battery pack, or electricalconnections of the battery pack to vehicle systems. The operations alsoinclude generating an output indicative of the potential battery failuremechanism

In accordance with yet another aspect, a computer-readable storagedevice stores instructions that are executable by a processor to causethe processor to perform operations including obtaining cell conditiondata for each cell of a set of cells of a battery pack. The cellcondition data for a particular cell indicates a sensed condition of theparticular cell. The operations also include evaluating the cellcondition data and battery pack configuration data to identify apotential battery failure mechanism for the battery pack. The batterypack configuration data indicates one or more of physical connectionswithin the battery pack, physical connections of the battery pack to asupport structure of a vehicle, electrical connections within thebattery pack, or electrical connections of the battery pack to vehiclesystems. The operations further include generating an output indicativeof the potential battery failure mechanism.

In accordance with still another aspect, a system includes means forobtaining, for each cell of a set of cells of a battery pack, cellcondition data. The cell condition data for a particular cell indicatesa sensed condition of the particular cell. The system also includesmeans for evaluating the cell condition data and battery packconfiguration data to identify a potential battery failure mechanism forthe battery pack. The battery pack configuration data indicates one ormore of physical connections within the battery pack, physicalconnections of the battery pack to a support structure of a vehicle,electrical connections within the battery pack, or electricalconnections of the battery pack to vehicle systems. The system furtherincludes means for generating an output indicative of the potentialbattery failure mechanism.

Although certain aspects may be described herein in terms of batteryoperation for ground-based vehicles (e.g., cars), it is to be understoodthat the techniques of the present disclosure may be applicable to othertypes of vehicles, such as electric vertical takeoff and landing (EVTOL)aircraft, watercraft, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a particular embodiment of a system for batteryfailure prediction in accordance with the present disclosure.

FIG. 2 illustrates a particular embodiment of a method of batteryfailure prediction in accordance with the present disclosure.

FIG. 3 illustrates a set of graphs of various battery data over time inaccordance with the present disclosure.

FIG. 4 illustrates a set of graphs of several cell-by-cell battery dataanalyses in accordance with the present disclosure.

FIG. 5 illustrates a graph of predicted and actual battery data analysesfor a single vehicle in accordance with the present disclosure.

FIG. 6 illustrates a set of graphs of various battery data over time fora single vehicle in accordance with the present disclosure.

FIG. 7 illustrates an example of an informational display that can begenerated by the computing device of FIG. 1 .

FIG. 8 illustrates another example of an informational display that canbe generated by the computing device of FIG. 1 .

FIG. 9 illustrates another example of an informational display that canbe generated by the computing device of FIG. 1 .

FIG. 10 illustrates another example of an informational display that canbe generated by the computing device of FIG. 1 .

FIG. 11 illustrates another example of an informational display that canbe generated by the computing device of FIG. 1 .

FIG. 12 illustrates a particular embodiment of a method of battery alertprocessing in accordance with the present disclosure.

FIG. 13 illustrates a particular embodiment of a system that isgenerally operable to apply artificial intelligence principles tobattery technology.

FIG. 14 illustrates another particular embodiment of a system that isgenerally operable to apply artificial intelligence principles tobattery technology.

FIG. 15 illustrates another particular embodiment of a system that isgenerally operable to apply artificial intelligence principles tobattery technology.

FIGS. 16A and 16B illustrate particular embodiments of methods ofoperation in accordance with the present disclosure.

FIG. 17 illustrates a particular example of a system that is operable tosupport cooperative execution of a genetic algorithm and abackpropagation trainer for use in developing models to supportapplication of artificial intelligence principles to battery technology.

FIG. 18 illustrates a particular example of a model developed by thesystem of FIG. 17 .

FIG. 19 illustrates particular examples of first and second stages ofoperation at the system of FIG. 17 .

FIG. 20 illustrates particular examples of third and fourth stages ofoperation at the system of FIG. 17 .

FIG. 21 illustrates a particular example of a fifth stage of operationat the system of FIG. 17 .

FIG. 22 illustrates a particular example of a sixth stage of operationat the system of FIG. 17 .

FIG. 23 illustrates a particular example of a seventh stage of operationat the system of FIG. 17 .

FIG. 24 is a block diagram of a computer system configured to initiate,perform, or control one or more of the operations described withreference to FIGS. 1-23 .

DETAILED DESCRIPTION

Particular aspects of the present disclosure are described below withreference to the drawings In the description, common features aredesignated by common reference numbers throughout the drawings. As usedherein, various terminology describing particular implementations is notintended to be limiting. For example, the singular forms “a,” “an,” and“the” are intended to include the plural forms as well, unless thecontext clearly indicates otherwise. It may be further understood thatthe terms “comprise,” “comprises,” and “comprising” may be usedinterchangeably with “include,” “includes,” or “including.”Additionally, it will be understood that the term “wherein” may be usedinterchangeably with “where.” As used herein, “exemplary” may indicatean example, an implementation, and/or an aspect, and should not beconstrued as limiting or as indicating a preference or a preferredimplementation. As used herein, an ordinal term (e.g., “first,”“second,” “third,” etc.) used to modify an element, such as a structure,a component, an operation, etc., does not by itself indicate anypriority or order of the element with respect to another element, butrather merely distinguishes the element from another element having asame name (but for use of the ordinal term). As used herein, the term“set” refers to a grouping of one or more elements, and the term“plurality” refers to multiple elements.

In the present disclosure, terms such as “determining,” “calculating,”“estimating,” “shifting,” “adjusting,” etc. may be used to describe howone or more operations are performed. It should be noted that such termsare not to be construed as limiting and other techniques may be utilizedto perform similar operations. Additionally, as referred to herein,“generating,” “calculating,” “estimating,” “using,” “selecting,”“accessing,” and “determining” may be used interchangeably. For example,“generating,” “calculating,” “estimating,” or “determining” a parameter(or a signal) may refer to actively generating, estimating, calculating,or determining the parameter (or the signal) or may refer to using,selecting, or accessing the parameter (or signal) that is alreadygenerated, such as by another component or device.

As used herein, “coupled” may include “communicatively coupled,”“electrically coupled,” or “physically coupled,” and may also (oralternatively) include any combinations thereof. Two devices (orcomponents) may be coupled (e.g., communicatively coupled, electricallycoupled, or physically coupled) directly or indirectly via one or moreother devices, components, wires, buses, networks (e.g., a wirednetwork, a wireless network, or a combination thereof), etc. Two devices(or components) that are electrically coupled may be included in thesame device or in different devices and may be connected viaelectronics, one or more connectors, or inductive coupling, asillustrative, non-limiting examples. In some implementations, twodevices (or components) that are communicatively coupled, such as inelectrical communication, may send and receive electrical signals(digital signals or analog signals) directly or indirectly, such as viaone or more wires, buses, networks, etc. As used herein, “directlycoupled” may include two devices that are coupled (e.g., communicativelycoupled, electrically coupled, or physically coupled) withoutintervening components.

FIG. 1 illustrates a particular embodiment of a system 100 for batteryfailure prediction in accordance with the present disclosure. The system100 includes a plurality of vehicles 102, 104, and 106, one or morecomputing devices 120, a maintenance database 146, and one or moredisplays on a display device 150. In FIG. 1 , the vehicles 102, 104, 106are illustrated as automobiles. However, in other implementations, thesystem 100 includes other types of vehicles, such as aircraft,watercraft, or spacecraft, or other types of land vehicles, such astrucks, trains, or motorcycles.

Each of the vehicles 102, 104, 106 includes a battery pack and sensors,such as a battery pack 108 and sensors 110 of the vehicle 104. Thesensors includes battery sensors, environmental sensors, other sensors,or a combination thereof. For example, in FIG. 1 , the sensors 110 ofthe vehicle 104 include a battery sensor 112, an environmental sensor114, and other sensors 116. The other sensors 116 can include positionsensors, movements sensors, image sensors, audio sensors, or othersensors to gather data that is used to characterize an operator of thevehicle 104 (e.g. a driver), maintenance conditions or faults associatedwith the vehicle 104, or other information. The battery sensors 112 caninclude sensors within the battery pack 108, sensors external to andcoupled to the battery pack 108, or both.

The sensors 110 are configured to monitor operations of the vehicle 104,including activity of the driver, to generate sensor data 118. Thesensor data 118 is provided continuously or occasionally (e.g.,periodically, when the vehicle 104 is at a particular location, when thevehicle 104 is coupled to a particular network connection, when thevehicle 104 is charging, etc.) to the computing device(s) 120. As anexample, the vehicle 104 can upload the sensor data 118 to the computingdevice(s) 120 via a network connection when the vehicle 104 is at a homelocation.

The sensor data 118 can include raw data generated by the sensors 110,analytic data generated based on raw data from the sensors 110, asummary of the raw sensor data, or combinations thereof. Examples of rawsensor data include battery voltage readings from the battery sensors112. Examples of summaries of the raw sensor data include averages,ranges, or other statistical summaries. Examples of analytic datagenerated based on raw data include battery state of health data,vehicle speed or acceleration data derived from multiple positionreadings, etc.

The computing device(s) 120 includes one or more processors 124 and oneor more memory devices 122. The memory device(s) 122 store instructions130 that are executable by the processor(s) 124 to perform analysis andother operations based on the sensor data 118 in order to projectbattery failures, to identify battery flaws, to characterize drivers, orcombinations thereof, as explained further below. The memory device(s)122 also store data that is used by or generated by the processor(s)124, such as driver type profiles 132, driver type groups 134, drivercharacterization data 136, other data or settings, or a combinationthereof.

In FIG. 1 , the computing device(s) 120 also include one or morecommunication interfaces 126 to communicate with the vehicles 102, 104,106 or with a server or data collection system that communicates withthe vehicles 102, 104, 106. The communication interface(s) 126 can alsobe configured to communicate with other computing devices or datarepositories, such as with a maintenance database 146. The communicationinterfaces(s) 126 include, for example, network interfaces, businterfaces, transceivers, etc. The computing device(s) 120 also includeone or more input/output (I/O) interfaces 128. The I/O interface(s) 128enable the computing device(s) 120 to interact more readily with a user.For example, in FIG. 1 , the I/O interface(s) 128 are coupled to thedisplay device 150 to enable the computing device(s) 120 to presentoutput data to a user or to receive input from the user.

In FIG. 1 , the instructions 130 include data pre-processinginstructions 140, a trained model 142, and data post-processinginstructions 144. The data pre-processing instructions 140 areexecutable by the processor(s) 124 to receive the sensor data 118 and/orother data and to prepare the received data for analysis. For example,the data pre-processing instructions 140 can detect and remove outlierdata, time align data from different sensors or different vehicles,perform calculations with the data to generate different data (e.g.,calculate a power value based on a current value and a voltage value inthe sensor data 118), etc. To illustrate, the data pre-processinginstructions 140 can generate the driver characterization data 136 basedon the sensor data 118. As another example, the data pre-processinginstructions 140 can extract features from the sensor data 118 or datagenerated by the data pre-processing instructions 140. To illustrate,the trained model 142 can be configured to receive an input featurevector, and the data pre-processing instructions 140 can generate theinput feature vector based on the sensor data 118 (and potentially otherdata).

The trained model 142 is a machine learning-based data model, such as aneural network, a decision tree, a support vector machine, anautoencoder, a random forest, a regression model, a Bayesian model, anaive Bayes model, a perceptron, a Boltzmann machine, deep beliefnetworks, a convolutional neural network, another machine-learningmodel, or an ensemble, variant, or other combination thereof. In someimplementations, the trained model 142 includes or corresponds to aclassifier. In some implementations, the trained model 142 can begenerated using an automated model building process, such as the processdescribed with reference to FIGS. 17-24 .

The trained model 142 is configured to receive the sensor data 118 ordata from the data pre-processing instructions 140 (e.g., a featurevector based on the sensor data 118) and to generate model output 152.The model output 152 includes, for example, a driver type profile 132,an assignment of the driver to a driver type group 134, the drivercharacterization data 136, a battery failure timeline 154, or acombination thereof. As a particular example, the trained model 142 mayassociate a driver with a driver type profile 132 based on the drivercharacterization data 136, which the data pre-processing instructions140 determine based on the sensor data 118. In this contexts,“instructions determining” data or information refers to theprocessor(s) 124 executing the instructions 140 based on input data togenerate output indicating the determined data or information. Forexample, in some implementations, the model output 152 includes thedriver type profile 132 of a driver, and the post-processinginstructions 144 estimate the battery failure timeline 154 based on thedriver type profile 132. In this context, “battery failure timeline”refers to at least an expected end-of-useful life date or time of thebattery pack 108 or of a particular cell of the battery pack 108. Toillustrate, each driver type profile 132 can be mapped to acorresponding set of battery failure timelines 154 (e.g., one or morebattery failure timelines 154 that are typical or expected forparticular types of driver). In this illustrative example, the trainedmodel 142 outputs a driver type profile 132 and the post-processinginstructions 144 look up the battery failure timeline 154 based on thedriver type profile 132. In other examples, the model output 152 fromthe trained model 142 includes both the driver type profile 132 and thebattery failure timeline 154.

In FIG. 1 , the model output 152 is displayed via the display device150. In other examples, the model output 152 is also, or in thealternative, stored at the memory device(s) 122 for further analysis bythe data post-processing instructions 144.

The data post-processing instructions 144 are configured to evaluate themodel output 152, potentially in conjunction with other data, to provideoutput to a user. In some implementations, the data post-processinginstructions 144 include graphical user interface instructions toarrange the model output 152 into a user-friendly format. Additionally,or in the alternative, the data post-processing instructions 144 includeinstructions to determine the battery failure timeline(s) 154 based onthe driver characterization data 136, the driver type profiles 132, thedriver type groups 134, the sensor data 118, historical battery failuredata 148, or combinations thereof. As an example, the maintenancedatabase 146 can store the historical battery failure data 148 alongwith other relevant data, such as a driver type profile of each driverassociated with a battery failure in the historical battery failure data148, sensor data 118 associated with each historical battery failure,etc. In this example, the data post-processing instructions 144 estimatethe battery failure timeline 154 for a particular vehicle 104 bycomparing the driver type profile 132 or sensor data 118 associated withthe particular vehicle 104 to the historical battery failure data 148 todetermine an average battery failure timeline for drivers of the drivertype. In some implementations, the data post-processing instructions 144can also account for a vehicle type of the particular vehicle 104, thebattery pack type of the battery pack 108, for an operating environmentof the particular vehicle 104, or other date to ensure that relevanthistorical battery failure data 148 is used to determine the batteryfailure timeline 154.

In some implementations, the driver characterization data 136 indicatesone or more of distances traveled, charging and/or discharging behavior,travel speed, acceleration and/or deceleration behavior, auxiliaryequipment usage, driving environment, other data descriptive of how aparticular driver operates a particular one of the vehicles 102, 104,106 over a period of time, or combinations thereof. In suchimplementations, the period of time represented by the drivecharacterization data includes multiple discharging operations andmultiple recharging operations of battery pack 108 of the vehicle 104.To illustrate, the time period can include or represent multiple days,weeks, months, seasons, or years. In some such implementations, theperiod of time includes at least one year to capture a significant andrepresentative data set over a period of time that includes differentdriving environments, different types of drives, and that likelyincludes data representing some change in functionality of the batterypack 108.

In some implementations, the data post-processing instructions 144update or generate a maintenance resources schedule 156 based on thebattery failure timeline(s) 154, the driver characterization data 136,the driver type profiles 132, the driver type groups 134, the sensordata 118, historical battery failure data 148, or combinations thereof.For example, when the battery failure timeline 154 for a particularvehicle 104 indicates a likely impending failure for the battery pack108 or a cell of the battery pack 108 of the particular vehicle 104, thedata post-processing instructions 144 can update the maintenanceresources schedule 156 to indicate that particular spare parts, testequipment, technical manuals, technicians, or other maintenanceresources will be needed to service the particular vehicle 104.Scheduling maintenance resources in advance can be especially beneficialfor a maintenance location that is associated with multiple vehicles,such as a vehicle dealership. For example, when the battery failuretimelines 154 associated with the multiple vehicles (e.g., the vehicles102-106) indicate that several of the battery packs will need to betested or replaced soon, the maintenance location can order spare partsor equipment in advance, which allows the maintenance location to keep alower stock of parts or equipment on hand without inconveniencing tovehicle owners by making them wait for parts or equipment to arrive.

In some implementations, the data post-processing instructions 144predict warranty and/or maintenance costs 158 based on the batteryfailure timeline(s) 154, the driver characterization data 136, thedriver type profiles 132, the driver type groups 134, the sensor data118, historical battery failure data 148, or combinations thereof. Forexample, particular types of drivers (e.g., drivers with particulardriver type profiles 132 or members of particular driver type groups134) may tend to experience more frequent battery failures. The warrantycosts associated with such drivers may therefore exceed the warrantycosts associated with other types of drivers. To account for such costdifferences, the warranty and/or maintenance costs 158 predicted by thedata post-processing instructions 144 can be used to price a warrantyoffered to a particular driver. To illustrate, after the driver hasdriven a particular vehicle of long enough to be assigned a driver typeprofile 132 or to be assigned to a driver type group 134, the driver canbe offered a warranty or maintenance program which is priced based onthe driver's driver type.

In some implementations, the instructions 130 can also includeinstructions that are executable by the processor(s) 124 to identify apotential battery failure mechanism for a battery pack based on thesensor data 118. For example, the sensor data 118 can include data forindividual cells of the battery pack 108, referred to herein as cellcondition data. The cell condition data for a particular cell indicatinga sensed condition of the particular cell, such as a sensed voltage, asensed discharge current, a sensed charging current, a sensedtemperature, chemical or mechanical properties, etc. In suchimplementations, the instructions 130 can evaluate the cell conditiondata along with battery pack configuration data to identify a potentialbattery failure mechanism for the battery pack. The battery packconfiguration data indicates one or more of physical connections withinthe battery pack, physical connections of the battery pack to a supportstructure of a vehicle, electrical connections within the battery pack,or electrical connections of the battery pack to vehicle systems. If theinstructions 130 identify a potential battery failure mechanism, theinstructions 130 generate an output indicative of the potential batteryfailure mechanism.

During operation of a particular implementation of the system 100, thecomputing device(s) 120 obtain driver characterization data 136 based onthe sensor data 118 from the sensors 110 onboard the vehicle 104. Thesensor data 118 is captured during a time period that includes multipledischarging operations and multiple recharging operations of a batterypack 108 of the vehicle 104. The processor(s) 124 provide the drivercharacterization data 136 as input to the trained model 142 to generatethe model output 152 which is displayed (via the display device 150) toa user, stored in at the memory device(s) 122, or both. The processor(s)124 estimate the battery failure timeline 154 for the battery pack 108based on the model output 152. The battery failure timeline 154 is alsodisplayed (via the display device 150) to the user, stored in at thememory device(s) 122, or both. Thus, the system 100 enables forecastingof battery failures for individual vehicles based on the type of driverassociated with each vehicle. This information can be used to makefurther predictions, such as to schedule maintenance or maintenanceresources, to estimate warranty or maintenance costs, or to assist withidentifying particular battery failure mechanisms.

FIG. 2 illustrates a particular embodiment of a method 200 of batteryfailure prediction in accordance with the present disclosure. The method200 can be performed by the system 100, such as by one or more of theprocessor(s) 124 executing the instructions 130.

The method 200 includes, at 202, obtaining driver characterization databased on sensor data from one or more sensors onboard a vehicle. Forexample, the computing device(s) 120 can obtain the sensor data 118 byreceiving a transmission that includes the sensor data 118 or by readingthe sensor data 118 from a memory, such as a memory onboard one of thevehicles 102-106 or a memory of a server that communicates with thevehicles 102-106. The sensor data 118 is captured during a time periodthat includes multiple discharging operations and multiple rechargingoperations of a battery pack of the vehicle. For example, in someimplementations, the time period includes portions of at least twoseasons (e.g., Spring and Summer) or at least one year. The sensor data118 includes data determined by at least one sensor within the batterypack 108 (e.g., the battery sensors 112), data determined by at leastone sensor coupled to the battery pack (e.g., the other sensors 116), atleast one environmental sensor 114, or combinations thereof. In someimplementations, the driver characterization data indicates informationsuch as distances traveled by the driver, charging and/or dischargingbehavior of the driver, travel speeds of the vehicle, accelerationand/or deceleration behavior of the driver, auxiliary equipment usage(e.g., usage of air conditioning, heating, etc.), driving environmentsin which the vehicle was operated, etc.

The method 200 includes, at 204, providing the driver characterizationdata as input to a trained model to generate a model output. Forexample, the driver characterization data 136 is provided to the trainedmodel 142. In this example, the trained model 142 is a machinelearning-based data model, such as a classifier. To illustrate, thetrained model 142 may be trained to associate a driver with a drivertype profile 132 based on the driver characterization data 136.

The method 200 includes, at 206, estimating a battery failure timelinefor the battery pack based on the model output. For example, in someimplementations, the driver type profile 132 is associated with (e.g.,mapped to) the battery failure timeline 154. In such implementations,the trained model 142 determines the driver type profile 132 as themodel output 152, and the data post-processing instructions 144determine the battery failure timeline 154 based on the driver typeprofile 132. In other implementations, the trained model 142 determinesthe battery failure timeline 154 as the model output 152 (e.g., withoutdetermining the driver type profile 132) or determines both the batteryfailure timeline 154 and the driver type profile 132 based on the drivercharacterization data 136.

In some implementations, the method 200 includes, at 208, schedulingmaintenance for the vehicle based on the battery failure timeline. Forexample, when the battery failure timeline 154 indicates that batteryfailure is imminent, the computing device(s) 120 may notify the driver,update the maintenance resource schedule 156, or both.

In some implementations, the method 200 includes, at 210, estimatingbattery failure timelines for battery packs of the multiple vehiclesusing the trained model. For example, the sensor data 118 can includedata captured by sensors onboard each of the vehicles 102-106. Toillustrate, the vehicles 102-106 can be associated with a singlemaintenance location (e.g., a vehicle dealership that providesmaintenance services) or maintenance service provider (e.g., a servicefranchise) that has multiple maintenance location that share resources(e.g., maintenance scheduling resources). In this illustrative example,the computing device(s) 120 can monitor the multiple vehicles 102-106 toestimate battery failure timelines and/or other battery maintenancerelated data.

In some implementations, the method 200 includes, at 220, predictingwarranty costs, maintenance costs, or both, based on battery failuretimeline(s). For example, a vehicle dealership can provide a customerwith a more accurate estimate of the useful life of the battery pack 108and/or the cost of ownership (including maintenance costs) of thevehicle based on the battery failure timeline(s). As another example,the vehicle dealership or another party can offer a driver a warrantyfor the battery pack 108 or the vehicle 104 that is prices based on thepredicted warranty cost.

In some implementations, the method 200 includes, at 230, schedulingmaintenance resources for a maintenance location based on an estimatedbattery failure timeline or multiple estimated battery failuretimelines. Examples of the maintenance resources include spare parts,test equipment, technical manuals, and technicians.

In some implementations, the method 200 includes, at 240, groupingdrivers of the multiple vehicles into driver type groups based on thedriver characterization data. For example, the computing device(s) 120can assign the drivers to the driver type groups 134 based on the drivercharacterization data 136. In such implementations, the method 200 mayalso include, at 242, obtaining actual battery failure data for at leasta subset of the multiple vehicles. For example, the battery failure data148 of the maintenance database 146 can include the actual batteryfailure data for at least the subset of the multiple vehicles 102-106.The method 200 may further include, at 244, identifying design ormanufacturing defects that tend to produce early battery failures forparticular driver types based on the driver type groups, the actualbattery failure data, and the estimated battery failure timelines. Insome implementations, the design or manufacturing defects are among aset of potential battery failure mechanism for the battery pack 108, andthe potential battery failure mechanism can be identified by evaluatingcell condition data and battery pack configuration data to identify apotential battery failure mechanism for the battery pack. In suchimplementations, the battery pack configuration data indicates, forexample, physical connections within the battery pack, physicalconnections of the battery pack to a support structure of a vehicle,electrical connections within the battery pack, electrical connectionsof the battery pack to vehicle systems, or combinations thereof.

FIG. 3 illustrates a set of graphs of various battery data over a periodof time in accordance with the present disclosure. The graphs of FIG. 3represent analysis of a battery pack of a single vehicle, such as thevehicle 104, by the computing device(s) 120 of FIG. 1 . In someimplementations, the computing device(s) 120 of FIG. 1 can present oneor more of the graphs of FIG. 3 to a user via the display device 150.

Graph 300 of FIG. 3 illustrates voltage of a battery pack over time. Asillustrated in the graph 300, as the vehicle is operated, the voltageresponds to changes in current (shown in graph 340). In graph 340, thecurrent move is negative when the battery pack is discharging, and thevoltage (in graph 300) generally trends downward as the battery packdischarges. Conversely, the current in graph 340 is positive when thebattery pack is charging (which can occur during a drive due torecuperative braking), and the voltage of the battery pack tends toincrease when the battery pack is charged.

Graph 320 illustrates that cell temperature within the battery packtends to increase as the battery pack is charged or discharged. Graph360 shows state of charge over time and illustrates that the generaltrend over the time period represented is toward a lower state ofcharge.

FIG. 4 illustrates a set of graphs of several cell-by-cell battery dataanalyses in accordance with the present disclosure. The graphs of FIG. 4represent analysis of a battery pack of a single vehicle, such as thevehicle 104, by the computing device 120 of FIG. 1 . In someimplementations, the computing device(s) 120 of FIG. 1 can present oneor more of the graphs of FIG. 4 to a user via the display device 150.

Graph 400 of FIG. 4 illustrates the average (e.g., mean) voltage of eachcell (represented by cell number) of a battery pack over a sampled timeperiod. Graph 400 illustrates that, during the sampled time period, thecells of the battery pack had a range of average voltages. The averagevoltage of cell number 25 appears to a statistical outlier, which mayindicate a problem with cell number 25 in particular. Thus, the graph400 can be help a user to identify the state of health of particularcells or groups of cells of the battery pack.

Graph 420 of FIG. 4 illustrates the standard deviation of voltage ofeach cell (represented by cell number) of the battery pack over thesampled time period. In the graph 420, every twelfth cell behavesmarkedly differently than the other cells, as illustrated by thedramatic dip in the standard deviation of every twelfth cell. Defects inthe battery pack can be identified by comparing the graph 420 to thephysical, electrical, and/or operational configuration of the cells inthe battery pack. For example, the data represented in the graph 420correspond to a battery pack with a faulty connection that affectedevery twelfth cell of the battery pack.

FIG. 5 illustrates a graph of predicted and actual battery data analysesfor a single vehicle in accordance with the present disclosure. Thegraph 500 represents analysis of a battery pack of a single vehicle,such as the vehicle 104, by the computing device 120 of FIG. 1 . In someimplementations, the computing device(s) 120 of FIG. 1 can present thegraph 500 to a user via the display device 150

The “Predicted” curve of the graph 500 was generated by a model, such asthe trained model 142 of FIG. 1 , that was trained to predict the nextvoltage value (e.g., the voltage value during a future sample period)based on the current state or prior state of the battery pack, such as acell voltage, current, and state of charge when the prediction isgenerated). The graph 500 shows close alignment between the predictedand actual voltage values, indicating that the model is accurate andthat the battery pack is behaving as predicted (e.g., does not exhibitanomalous behavior). In some examples, the trained model may be adjustedbased on differences between the “Predicted” and “Actual” curves, forexample by using backpropagation or another optimization/trainingmethod.

FIG. 6 illustrates a set of graphs of various battery data over time fora single vehicle in accordance with the present disclosure. The graphsof FIG. 6 represent analysis of a battery pack of a single vehicle, suchas the vehicle 104, by the computing device 120 of FIG. 1 . In someimplementations, the computing device(s) 120 of FIG. 1 can present oneor more of the graphs of FIG. 6 to a user via the display device 150.

The graphs 600 and 620 include a first portion (in blue) representingmeasured historical values, and a second portion (in orange)representing values predicted by a trained model such as the trainedmodel 142 of FIG. 1 . The graph 600 indicates voltage values for a cellof the battery pack during a time period, and the graph 620 indicatescurrent values for the cell during the time period.

The graph 640 represents risk values over time. In the present context,a higher risk value indicates a higher risk of failure of the cell, anda lower risk value indicates a lower risk of failure. Generally, therisk trends upward over time due to aging of the battery; however, thegraph 640 also illustrate spikes in risk that are due abnormal drivingbehavior.

FIGS. 7-11 illustrate various informational displays that can begenerated by the computing device 120 of FIG. 1 when the computingdevice 120 of FIG. 1 is used to track multiple vehicles, such as thevehicles 102-106 of FIG. 1 . FIG. 7 illustrates a display for trackingthe multiple vehicles by vehicle type (e.g., make and/or model),location, and driver type. For example, FIG. 7 includes a plurality ofgraphical elements (such as a first graphical element 702) positioned ona map display representing multiple geographic regions, such as regions724 and 726. The locations of the graphical elements indicate thegeneral region in which a vehicle represented by each graphical elementis frequently operated.

Each of the graphical elements includes information about the vehicletype of the vehicle and the driver type of the driver of the vehicle.For example, the first graphical element 702 includes an icon 704 and acentral region 706. The icon 704 and a coding feature (e.g., a color,fill pattern, or shape) of the central region 706 indicate the vehicletype of the vehicle represented by the first graphical element 702.Additionally, the first graphical element 702 includes a ring 708 thatincludes a coding feature (e.g., a color or a fill pattern) thatindicates the driver type (e.g., a driver type group 134 or a drivertype profile 132 of FIG. 1 ) of a driver of the vehicle represented bythe first graphical element 702.

FIG. 7 also includes a summary information area 710 in which summary oraggregate information about the vehicles is shown. In FIG. 7 , thesummary information area 710 includes an icon (such as an icon 712)representing each vehicle type, a first bar (e.g., bar 714) representinga count of the number of vehicles of the particular type, and a secondbar (e.g., bar 716) representing counts of the numbers of drivers ofeach driver type that drive the particular type of vehicle.

FIG. 8 illustrates a display 800 for presenting information aboutmultiple vehicles. In FIG. 8 , a first region 820 of the display 800includes graphical elements representing vehicles of a first vehicletype, and a second region 840 of the display 800 includes graphicalelements representing vehicles of a second vehicle type. The display 800also illustrates a detailed view of one of the graphical elements (e.g.,graphical element 802) to highlight the components of each graphicalelement.

In FIG. 8 , a central region includes the icon 704 representing thevehicle type of the vehicle represented by the graphical element 802.Rings (or partial rings) around the central regional 706 representvalues of particular parameters associated with the vehicle. In FIG. 8 ,each ring is coded (e.g., color coded or fill pattern coded) to visuallydistinguish the ring from adjacent rings. A length of the coded portionof each ring indicates a value (e.g., a normalized value) of the datarepresented by the ring. The rings include a first ring 804 representinga state of charge (SOC) of a battery pack of the vehicle, a second ring806 representing a state of health (SOH) of the battery pack of thevehicle, a third ring 808 representing a lag voltage of the battery packof the vehicle, and a fourth ring 810 representing a cell degradation ofthe battery pack of the vehicle.

FIG. 9 illustrates another display 900 for presenting information aboutmultiple vehicles. The display 900 is identical to the display 800 ofFIG. 8 except that the central region 706 of each graphical element iscoded to indicate a driver type of the vehicle. For example, in thegraphical element 802, the central region 706 is color coded to indicatethat a particular type of driver is associated with the vehiclerepresented by the graphical element 802.

FIG. 10 illustrates yet another display 1000 for presenting informationabout multiple vehicles. The display 1000 is identical to the display900 of FIG. 9 except in the display 1000, the vehicles are grouped indisplay regions 1020, 1040 based on driver behavior 904 or driver type.

FIG. 11 illustrates another display 1100 for presenting informationabout multiple vehicles. The display 1100 includes a set of graphicalelements (such as the graphical element 802) each of which represents acorresponding vehicle. Each vehicle is also associated with a graph(such as a graph 1104) representing measured, calculated, and/orpredicted values for particular battery condition parameters. Forexample, in FIG. 11 , the graph 1104 indicates state of charge over timefor the vehicle represented by the first graphical element 802. Further,the graph 1104 includes an alert indication 1110 that shows where thestate of charge over time deviates significantly (e.g., by more that athreshold amount) from a state of charge value predicted by a trainedmodel (such as the trained model 142 of FIG. 1 ). The alert indication1110 indicates that the battery pack of the vehicle (or associatedhardware and circuitry, such as a charging controller) may need service.The system 100 can schedule the service, schedule a maintenanceresource, send a notification to the driver of the vehicle, or performother operations responsive to the alert indication 1110.

FIG. 12 illustrates a particular embodiment of a method 1200 of batteryalert processing in accordance with the present disclosure. In FIG. 12 ,the method 1200 is initiated in response to generation of the alertindication 1110 of FIG. 11 or another indication of a battery cell orbattery pack problem. In FIG. 12 , the system 100 determines a risklevel and confidence level associated with the alert indication 1110. Ifthe alert indication 1110 is low risk, low confidence, or both (at1210), the system 100 notifies a party 1212 responsible for designing,manufacturing, or maintaining the vehicle. In this example, the party1212 can re-evaluate or further evaluate the underlying data use togenerate the alert indication 1110 and, based on this re-evaluation orfurther evaluation, notify the vehicle owner, update the system 100, ordo nothing. If the alert indication 1110 is high risk, high confidence,or both (at 1206), the system 100 notifies the party 1212 and thevehicle owner 1208. For example, the system 100 can notify both theparty 1212 and the vehicle owner 1208 that maintenance has beenscheduled for, or should be scheduled for, the vehicle.

Although various aspects may be described herein as utilizing drivercharacterization data to predict a battery failure timeline, inadditional or alternative aspects, sensor data (including but notlimited to battery-related sensor data) may be used to predict driverbehavior. In some cases, a vehicle may automatically perform certainoperations and provide feedback to the driver based on battery-relateddata. As an example, if a battery has relatively low charge or health,throttle responsiveness may be reduced, gear ratios may be adjusted,climate control settings may be made less power-hungry, etc. Conversely,if a battery has relatively high charge or health, throttleresponsiveness may be increased, gear ratios may enable holding gearslonger so that the vehicle exhibits improved torque performance andhigher engine rotations per minute (RPM), and traction control systemsmay be adjusted if it is safe to do so.

The techniques of the present disclosure may enable various operationsat a vehicle based on a determined driver profile. Such operations canbe perceived as the vehicle automatically adjusting to optimizeperformance for a specific driver. As an illustrative non-limitingexample, a specific brake pressure curve may be determined as being usedby a driver (or driver profile) under certain conditions (e.g., speed,weather, road conditions, bank angle, etc.). However, a different brakepressure curve may provide better vehicle performance in suchconditions, where that better brake pressure curve is specified by thevehicle manufacturer, is determined by a machine learning model, isdetermined based on data from other vehicles/drivers, is determined in asimulator environment, etc. In this example, the vehicle mayautomatically electro-actuate the braking system to make up thedifference between the driver's brake pressure curve and the preferredbrake pressure curve. As another example, if the driver of a roadvehicle (or, as another example, a pilot of an aerial vehicle) exhibitsless-than-optimal tendencies, feedback may be provided to the driver. Toillustrate, the driver may be shown, via a computer monitor, heads-updisplay, etc., what the driver is doing incorrectly and what theyinstead should have done to improve performance. The driver may even beplaced in a vehicle simulation environment to try and achieve targetscorresponding to the behavior the driver is to “learn.”

FIGS. 13-24 illustrate additional details regarding applying artificialintelligence and machine learning principles to battery technology. Thevarious systems and method described with reference to FIGS. 13-24 canbe included with or used to facility the operation of the system 100 ofFIG. 1 .

FIG. 13 illustrates a particular embodiment of a system 1300 thatincludes a charge controller 1310 coupled to a battery 1320. In theillustrated example, the battery 1320 is a battery pack that includesmultiple battery cells 1322, though in alternative examples the battery1320 may be a single-cell battery. The battery 1320 may generally be anytype of battery. Examples of battery types include, but are not limitedto, rechargeable, non-rechargeable, lead acid, alkaline, nickel-metalhydride (NiMH), lithium ion, nickel cadmium (NiCd), etc. In a particularimplementation, the system 1300 includes, corresponds to, or is includedwithin the system 100 of FIG. 1 .

FIG. 13 further illustrates one or more sensors 1324 coupled to thecells 1322. In various embodiments, sensors 1324 may be coupled toindividual cells, collectively coupled to multiple cells, may be presentwithin the battery 1320, may be placed external to the battery 1320,etc. The sensors 1324 may collectively generate sensor data 1330 thatreflects various operational and environmental characteristicsassociated with the battery 1320. Examples of sensor types include, butare not limited to, temperature, vibration, voltage, current,acceleration, motion, state of charge, etc. Certain sensors 1324 mayprovide sensor data 1330 related to a larger device that is coupled toor otherwise associated with the battery 1320. For example, if thebattery 1320 is associated with an electric or hybrid automobile, thesensors 1324 may include automotive sensors that measure propertiesassociated with tire rotation, engine operation, thrust, braking,coolant levels, air flow, manifold pressure, oxygen level, fuel,exhaust, passenger/cargo load, environmental (e.g., weather) conditions,etc.

The sensor data 1330 may be stored at a storage device 1340. A trainingdata set 1342 may be formed based on the sensor data 1330, and,optionally, sensor data from other sensor(s) associated with one or moreother batteries 1350. To illustrate, the training data set 1342 may beformed based on sensor data received from sensors that measurecharacteristics of similar batteries, similar types of batteries,similar operating environments, etc. As an example, the training dataset 1342 may be formed based on sensor data for vehicle batteries in thesame make/model of vehicle. It is to be understood that the data storagedevice 1340 may be located near the battery 1320 (e.g., in the same caras the battery 1320) or may be located remotely and accessible vianetwork communication.

A model generator 1360 may generate a model 1370 based on the trainingdata set 1342. In the illustrated example, the model 1370 is generatedbased on execution of a neuroevolutionary process (e.g., a geneticalgorithm 1362) and optimization training (e.g., backpropagation 1364),though it is to be understood that different model generation techniquesmay be used in other examples. The model generator 1360 may in somecases correspond to hardware circuitry, software instructions, or acombination thereof. For example, the model generator 1360 may besoftware application executed by a computing device, anInternet-accessible cloud service, etc. Particular aspects of modelgeneration are further described with reference to FIGS. 17-23 .

The model 1370 may be provided to (e.g., downloaded to) the computingdevice(s) 120, the charge controller 1310, or to processor(s) thatexecute the model 1370. For example, the charge controller 1310 orprocessor(s) may receive sensor data 1330 from the battery 1320 and mayinput the sensor data 1330 into the model 1370 to generate model output.The model output may influence operation of the charge controller 1310.To illustrate, the model output may indicate when to begin charging thebattery 1320 or a cell 1322, when to stop charging the battery 1320 orthe cell 1322, at what level (e.g., charging voltage or current draw) tocharge the battery 1320 or the cell 1322, etc.

In some examples, the model output may also predict future batteryperformance and/or future battery failure. To illustrate, the trainingdata set 1342 may include labeled sensor data 1330 corresponding to timeperiods that preceded battery failure (or cell failure), and the model1370 may thus be trained using supervised learning as a model configuredto output a prediction of an impending failure when sufficiently similarsensor data is measured by the sensors 1324 and input into the model1370.

In yet another example, model output may predict or indicate“optimality,” e.g., whether the battery 1320 or a cell 1322 thereof isfunctioning as it should or is expected to according to battery/cellspecifications. In some cases, optimality may be considered in view ofenvironmental factors, such as how ambient temperature and humidityconditions affect battery charging/discharging. By training the model1370 using historical sensor data that was collected over a period oftime, the model 1370 may reflect battery performance over time undercertain conditions in certain environments, and model output may thus beused to determine improved battery charging and/or usage parameters thattake performance over time into account.

In some examples, the training data set 1342 may be used to generaterules 1380. To illustrate, if the training data set 1342 indicates thatthe battery 1320 is often exposed to high temperatures (e.g., overninety degrees Fahrenheit), the rules 1380 may indicate that the battery1320 is to be charged using a lower-than-normal charging voltage. Asanother example, if the training data set 1342 indicates that thebattery 1320 is often exposed to low temperatures (e.g., under zerodegrees Fahrenheit), the rules 1380 may indicate that the battery is tobe charged using a higher-than-normal charging voltage. As yet anotherexample, the rules 1380 may indicate that the charging voltage for thebattery 1320 is to be dynamically determined based on ambienttemperature, and may optionally indicate a specific charging voltagedecrease/increase per degree increase/decrease in ambient temperature.Additional examples of the rules 1380 include rules regarding whether toactivate selective charge routing, selective temperature monitoring,etc.

The model 1370 and the rules 1380 may thus represent an example of usingenvironmental data (and/or other relevant data) and machine learning toimprove battery performance. In some aspects, machine learning modelsmay be trained using historical performance/health data in addition toenvironmental data to predict recommended charging and dischargingconditions for a battery or cell thereof. In a particular aspect, atrained model may be used to suggest battery maintenance operations orprovide other in-use reports. In yet another aspect, a trained model maybe used to suggest battery, load, or charging features for a particularuse case and/or environment. To illustrate, a different model 1370 maybe used depending on heat patterns, climate, vehicle usage patterns,passenger load patterns, etc. Thus, in some cases, different models maybe used for city driving vs. freeway driving, for summer vs. winter, fordriver-only trips vs. entire-family trips, etc.). Putting machinelearning functionality into (e.g., the charge controller 1310 of) adevice, for example a vehicle, may enable updates to improve/tune amodel to a specific vehicle/battery pair. If a battery moves from oneload to another, machine learning functionality may move with thebattery and adapt to the new load if/when needed. In some examples,machine learning output may be provided to battery design teams,maintenance staff, etc., for example for use in configuring operatingtemperature ranges, battery position within a device/vehicle withrespect to other items (e.g., insulation, heat sink, active cooling),etc.

The system 1300 of FIG. 13 may also enable an “online” aspect to batteryoperation. To illustrate, various electronic devices, vehicles, etc. mayupload sensor data to a server or cloud-accessible service. Theserver/service may use such sensor data, in individual and/or aggregateform, to generate and deploy customized machine learning solutions,which may be downloaded back to the devices, vehicles, etc. Asconditions change, model updates may be provided so that the variousdevices, vehicles, etc. experience improved battery charging/dischargingperformance.

FIG. 14 illustrates another embodiment of a system 1400 that includesthe charge controller 1310 and the battery 1320. The charge controller1310 is coupled to one or more processors 1412 and a rules engine 1414.In alternate implementations the processors 1412 and/or the rules engine1414 may be a part of the charge controller 1310. In some aspects, theprocessors 1412 provide input (e.g., the sensor data 1330) to a machinelearning model (e.g., the model 1370), to generate model output. Therules engine 1414 may operate based on rules (e.g., the rules 1380) todetermine aspects of battery charging/discharging, as described withreference to FIG. 13 . The charge controller 1310 includes a controlcircuit 1416 that selectively connects a power supply signal (ormodified version thereof, as further described herein), to the battery1320.

In the example of FIG. 14 , the battery 1420 is a multi-cell battery,where each cell is designated by a number, e.g., “Cell 0” 1451, “Cell 1”1452, . . . “Cell N” 1453. Each cell may be coupled to one or morecontrol circuits (e.g., control circuits 1421, 1422, 1423, 1431, 1432,1433) that switch the cells in and out of a charging path and/or adischarging path. In some examples, control circuits may enableconnecting cells in series in a discharge path to provide ahigher-voltage power source.

In some examples, output from the processors 1412 and/or the rulesengine 1414 may be used to determine operation at the various controlcircuits 1416, 1421-1423, 1423-1433. For example, the control circuit1416 may selectively couple the power supply to the battery 1320 basedon whether model/rules engine output indicates that charging isrecommended. In some examples, output that is generated by executing atrained prediction model and/or a rules engine may result in selectivelycharging or discharging some cells but not other cells, or at leastcharging or discharging some cells before charging or discharging othercells. Factors that may lead to such output at the trained predictionmodel or rules engine may include, but are not limited to, a cell havinga higher possibility of overheating/thermal runaway than another cell, acell being predicted to have less capacity than another cell, etc. Inanother example, charging or discharging of “healthier” cells may beprioritized, where “health” is determined based on capacity, state ofcharge, charging time, discharging time, idle/self discharging time,leakage, internal resistance, age, temperature, predicated likelihood offailure, one or more other characteristics or metrics, or anycombination thereof. In some examples, the control circuit 1416 mayconvert the power supply (e.g., in terms of voltage, alternating vs.direct current, etc.) and provide a converted supply to the battery1320. In yet another example, the control circuit 1416 may use inductivecoupling between one or more inductor pairs to selectively adjust amagnitude (e.g., in voltage or amperes) of the charging supply providedto the battery 1320, such as based on ambient temperature, as describedwith reference to FIG. 13 .

Although one multi-cell battery 1320 is shown in FIG. 13 , it is to beunderstood that any number of single-cell and/or multi-cell batteriesmay be present in the system 1400. In some cases, each battery has acorresponding charge controller. In other cases, a single chargecontroller is provided for multiple batteries. In some cases, a chargecontroller is provided for each cell within each battery, and in suchcases the charge controllers may reside within the batteries. Further,although illustrated as block “control circuits” for ease ofexplanation, it is to be understood that the control circuits shown inFIG. 14 may include various constituent electrical components dependingon implementations, such as resistors, capacitors, transistors/switches,inductors, etc. The specific wiring of the control circuits may bedetermined based on the use case and environment of the battery. Toillustrate, different control circuits may be used depending on how manycells can be simultaneously charged, whether and how many are to besimultaneously discharged to provide sufficient voltage for deviceoperation, etc.

The cell-specific control circuits 1421-1423, 1431-1433 may becontrolled based on output from the processors 1412 and/or the rulesengine 1414. For example, an individual cell 1451-1453 may be put intoone of three different states based on output from the processors 1412and/or the rules engine 1414. As an example, the first cell 1451 may beconnected into a charging path while being disconnected from adischarging path, the second cell 1452 may be disconnected from both thecharging path and the discharging path (e.g., may be in an“idle”/“unused”) state, and the third cell 1453 may be disconnected fromthe charging path while being connected to the discharging path.

Thus, the system of FIG. 14 represents a “switchable battery fabric”that enables individual batteries, or cells thereof, to be charged anddischarged based on output from a machine learning model or a rulesengine. Such granular operation may provide various benefits. Toillustrate, a cell that is predicted to fail may be electricallyisolated from other cells, thereby reducing the chances of the failedcell adversely impacting operation of other cells and/or the battery asa whole. As another example, a battery can be built with more cells thanneeded for a given load, so that some cells can be charged and madeready while other cells are discharging, thereby providing for a morerobust, relatively uninterrupted power supply. The system of FIG. 14thus enables “multiplexing” of batteries in and out of variouselectrical paths on a predictive basis based on operation of artificialintelligence (e.g., machine learning) algorithms.

In some cases, to accomplish selective “multiplexing” of batteries/cellsin and out of charging/discharging paths, an array of switches may beused. However, each switch may increase overall cost of the powersubsystem within a vehicle, grid, etc. In accordance with another aspectof the present disclosure, each battery or cell thereof is connected toa “smart” controller, and a combined power and control signal isprovided to each such controller. For example, referring to FIG. 15 ,three batteries/cells 1501, 1502, 1503 have respective identifiers (IDs)000, 001, and 111, and each battery/cell is connected to a correspondingcontroller 1511, 1512, 1513. The controllers 1511-1513 are connected viaa common bus, on which a combined power and control input 1520 isprovided. Although the terminology of a “signal” is used and a single“wire” is shown in FIG. 15 , it is to be understood that depending onimplementation, the combined power/control input may be provided overany number of conductors. Examples of combined power/data communicationinclude Power over Ethernet, Powerline, etc. In an illustrative example,power and control data are transferred on the same conductor(s) atdifferent frequencies. To illustrate, an AC power signal may have afrequency of 50 hertz (Hz) or 60 Hz, whereas control data may be sent ata much higher frequency, for example between 2 and 88 megahertz (MHz) inpowerline-type systems. In a power-over-ethernet-type system, a powersignal may be “injected” onto one or more pairs of conductors of acable/wire, where such conductors may also be carrying data signals ormay be different from the conductors dedicated for data signalcommunication. In a combined DC power and data signal, the data may bemodulated onto a high-frequency carrier signal that is communicated onthe same line(s) that carry the DC power. The frequency of the carriersignal may be selected based on system characteristics, interferencepatterns, etc.

At the physical (PHY) and media access control (MAC) layers, datacommunication may be associated with various parameters, the values ofwhich may be based on what specific set of protocols is in use. Examplesof such parameters may include, but are not limited to, one or more offorward error correction (FEC) coding, number of carriers, modulationscheme, interleaver parameters, sampling frequency, symbol duration,intercarrier spacing, guard interval duration, transform size (e.g.,Fourier transform (FFT)/inverse FFT (IFFT) size), frame/block size, etc.Depending on implementation, communication in the system of FIG. 15 maybe unidirectional, half-duplex, or full-duplex.

A signaling protocol may be used to enable individually addressing eachof the batteries/cells 1501-1503 in the switchable battery fabric viatheir corresponding controllers 1511-1513. An illustrative non-limitingexample of such a protocol is shown at the top of FIG. 15 . In theexample shown, command data directed to a specific battery or cellsbegins with a start flag (e.g., 10010) and ends with an end flag (e.g.,01001). The command data includes the ID of the addressed battery (e.g.,“000” for battery 1501, “001” for the battery 1502, or “111” for thebattery 1503). The command data also includes one or more commands.Examples of commands include commands to connect the identifiedbattery/cell to a specific charging path, set a charging signalmagnitude (e.g., in volts or amps) for the identified battery/cell to aparticular value, disconnect the identified battery/cell from a specificcharging path, connect the identified battery/cell to a specificdischarge path (or load), disconnect the identified battery/cell from aspecific discharge path (or load), etc.

It is to be understood that the architecture and protocol illustrated inFIG. 15 are merely exemplary and are not to be considered limiting.Alternative implementations may include different architectures and/orprotocols.

During operation, each of the controllers 1511-1513 (which in some casesmay be implemented using an electrical switch and comparator circuitry)monitors the combined input 1520. When a controller observes its own ID(e.g., the associated battery/cell's ID), the controller executes theprovided commands, such as to begin, adjusted, or terminate charging ordischarging of its associated battery/cell. Notably, such operations maybe performed predictively based on operation of machine learning modelsand rules engines, as described with reference to FIG. 13 .

In some aspects, a controller may also communicate information regardingits battery/cell (e.g., temperature metrics, leak detection, and/orother sensor data as described with reference to FIG. 13 ) back upstreamfor monitoring and/or use in determining what commands to communicate towhat batteries/cells in the future. Similarly, battery/cellspecifications may be stored by and communicated upstream by thecontroller. The controller may also communicate information regardingwhether a battery or cell is operating within the bounds of suchspecifications.

The system of FIG. 15 thus illustrates a device that receives combinedcontrol data and power on the same input terminal (designated “in” inFIG. 15 ). Based on whether the control data includes a particularidentifier of a corresponding battery/cell, control circuitry of thedevice may selectively connect the input terminal to an output terminal(designated “o” in FIG. 15 ), which may result in charging thecorresponding battery/cell. Use of such devices for battery managementin a switchable battery fabric may be simpler and/or less expensive thanusing complex M×N switches.

FIG. 16A illustrates a flowchart of a particular example of a method1600 of using a trained model to control battery charging. The method1600 may correspond to operations performed at the systems of FIGS. 13,14 , and/or 15.

The method 1600 includes receiving a trained model, at 1602, andreceiving sensor data from at least one sensor associated with abattery, at 1604. For example, the charge controller 1310 and/or theprocessor(s) 1412 may receive the model 1370 and the sensor data 1330.

The method 1600 also includes executing, by a processor, the trainedmodel, at 1606. Executing the trained model includes providing thesensor data as input to the trained model to generate a model output.For example, the processor(s) 1412 may provide the sensor data 1330 tothe model 1370 to generate a model output.

The method 1600 further includes sending, from the processor to a chargecontroller coupled to the battery, a control signal that is based on themodel output, at 1608. For example, the processors 1412 may send acontrol signal to the charge controller 1310. In a particular example,the control signal may include data represented in accordance with theaddressing protocol described with reference to FIG. 15 . Alternatively,or in addition, the control signal may be communicated as part of acombined power and control signal, as described with reference to FIG.15 .

The method 1600 includes automatically, by the charge controller,initiating or terminating charging of the battery based on the controlsignal, at 1610. For example, the charge controller 1310 may controloperation of one or more of the control circuits shown in FIG. 14 orFIG. 15 to initiate or terminate charging of a particular battery (orcell).

FIG. 16B illustrates a flowchart of a particular example of a method1620 of operation at a device that receives combined power and controlat an input terminal. The method 1620 may correspond to operationsperformed at the systems of FIGS. 13, 14 , and/or 15.

The method 1602 remains at 1622 until a control signal is received atthe input terminal. When a control signal is received, the method 1620continues to 1624. At 1624, the method 1620 includes determining whetheran identifier (ID) in the control signal matches an ID of a particularcell. If not, the method 1620 returns to 1622 (and the previouslyreceived control signal is disregarded). Although FIG. 16B illustrates amethod of operation at control circuitry for a particular battery cell,it is to be understood that the same method may concurrently be executedby multiple sets of control circuitry corresponding to multiple othercells, where each such control circuitry compares ID(s) in the controlsignal to the ID(s) of the battery cells coupled to that controlcircuitry.

If the IDs match, the method 1620 includes performing the command(s)indicated in the control data, at 1626, and the method 1620 then returnsto 1622. As an example, the method 1620 may include connecting the inputterminal to an output terminal so that the power signal being receivedat the input terminal is provided to the cell to charge the cell.Various commands may be included in the control data. Examples ofcommands include commands to connect the identified cell to a specificcharging path, set a charging signal magnitude (e.g., in volts or amps)for the identified cell to a particular value, disconnect the identifiedcell from a specific charging path, connect the identified cell to aspecific discharge path (or load), disconnect the identified cell from aspecific discharge path (or load), etc.

Various functionality described herein is associated with trainingand/or using trained models. FIGS. 17-23 illustrates particular examplesof a system 1700 that is operable to build such models, and theoperation of such a system 1700.

The system 1700, or portions thereof, may be implemented using (e.g.,executed by) one or more computing devices, such as laptop computers,desktop computers, mobile devices, servers, and Internet of Thingsdevices and other devices utilizing embedded processors and firmware oroperating systems, etc. In the illustrated example, the system 1700includes a genetic algorithm 1710 (e.g., the genetic algorithm 1362 ofFIG. 13 ) and a backpropagation trainer 1780 (e.g., the backpropagation1364 of FIG. 13 ). The backpropagation trainer 1780 is an example of anoptimization trainer, and other examples of optimization trainers thatmay be used in conjunction with the described techniques include, butare not limited to, a derivative free optimizer (DFO), an extremelearning machine (ELM), etc. The combination of the genetic algorithm1710 and an optimization trainer, such as the backpropagation trainer1780, may be referred to herein as an “automated model building (AMB)engine.” In some examples, the AMB engine may include or execute thegenetic algorithm 1710 but not the backpropagation trainer 1780, forexample in the case of certain reinforcement learning problems.

In particular aspects, the genetic algorithm 1710 is executed on adifferent device, processor (e.g., central processor unit (CPU),graphics processing unit (GPU) or other type of processor), processorcore, and/or thread (e.g., hardware or software thread) than thebackpropagation trainer 1780. The genetic algorithm 1710 and thebackpropagation trainer 1780 may cooperate to automatically generate aneural network model of a particular data set, such as an illustrativeinput data set 1702. In particular aspects, the system 1700 includes apre-processor 1704 that is communicatively coupled to the geneticalgorithm 1710. Although FIG. 17 illustrates the pre-processor 1704 asbeing external to the genetic algorithm 1710, it is to be understoodthat in some examples the pre-processor may be executed on the samedevice, processor, core, and/or thread as the genetic algorithm 1710.Moreover, although referred to herein as an “input” data set 1702, theinput data set 1702 may not be the same as “raw” data sources providedto the pre-processor 1704. Rather, the pre-processor 1704 may performvarious rule-based operations on such “raw” data sources to determinethe input data set 1702 that is operated on by the automated modelbuilding engine. For example, such rule-based operations may scale,clean, and modify the “raw” data so that the input data set 1702 iscompatible with and/or provides computational benefits (e.g., increasedmodel generation speed, reduced model generation memory footprint, etc.)as compared to the “raw” data sources.

As further described herein, the system 1700 may provide an automateddata-driven model building process that enables even inexperienced usersto quickly and easily build highly accurate models based on a specifieddata set. Additionally, the system 1700 simplify the neural networkmodel to avoid overfitting and to reduce computing resources required torun the model. Data sets from battery-associated sensors may include,for example, timestamped indications of battery/cell status, state ofcharge, charge rate, discharge rate, load characteristics (e.g., in thecase of vehicles, characteristics of propulsion/braking/climatecontrol/entertainment/safety/security systems), etc.

The genetic algorithm 1710 includes or is otherwise associated with afitness function 1740, a stagnation criterion 1750, a crossoveroperation 1760, and a mutation operation 1770. The genetic algorithm1710 may represent a recursive search process. Each iteration of thesearch process (also called an epoch or generation of the geneticalgorithm) may have an input set (or population) 1720 and an output set(or population) 1730. The input set 1720 of an initial epoch of thegenetic algorithm 1710 may be randomly or pseudo-randomly generated.After that, the output set 1730 of one epoch may be the input set 1720of the next (non-initial) epoch, as further described herein.

The input set 1720 and the output set 1730 may each include a pluralityof models, where each model includes, for example data representative ofa neural network. For example, each model may specify a neural networkby at least a neural network topology, a series of activation functions,and connection weights. The topology of a neural network may include aconfiguration of nodes of the neural network and connections betweensuch nodes. The models may also be specified to include otherparameters, including but not limited to bias values/functions andaggregation functions.

Additional examples of neural network models are further described withreference to FIG. 18 . In particular, as shown in FIG. 18 , a model 1800may be a data structure that includes node data 1810 and connection data1820. In the illustrated example, the node data 1810 for each node of aneural network may include at least one of an activation function, anaggregation function, or a bias (e.g., a constant bias value or a biasfunction). The activation function of a node may be a step function,sine function, continuous or piecewise linear function, sigmoidfunction, hyperbolic tangent function, or other type of mathematicalfunction that represents a threshold at which the node is activated. Thebiological analog to activation of a node is the firing of a neuron. Theaggregation function may be a mathematical function that combines (e.g.,sum, product, etc.) input signals to the node. An output of theaggregation function may be used as input to the activation function.The bias may be a constant value or function that is used by theaggregation function and/or the activation function to make the nodemore or less likely to be activated.

The connection data 1820 for each connection in a neural network mayinclude at least one of a node pair or a connection weight. For example,if a neural network includes a connection from node N1 to node N2, thenthe connection data 1820 for that connection may include the node pair<N1, N2>. The connection weight may be a numerical quantity thatinfluences if and/or how the output of N1 is modified before being inputat N2. In the example of a recurrent network, a node may have aconnection to itself (e.g., the connection data 1820 may include thenode pair <N1, N1>).

The model 1800 may also include a species identifier (ID) 1830 andfitness data 1840. The species ID 1830 may indicate which of a pluralityof species the model 1800 is classified in, as further described withreference to FIG. 19 . The fitness data 1840 may indicate how well themodel 1800 models the input data set 1702. For example, the fitness data1840 may include a fitness value that is determined based on evaluatingthe fitness function 1740 with respect to the model 1800, as furtherdescribed herein.

Returning to FIG. 17 , the fitness function 1740 may be an objectivefunction that can be used to compare the models of the input set 1720.In some examples, the fitness function 1740 is based on a frequencyand/or magnitude of errors produced by testing a model on the input dataset 1702. As a simple example, assume the input data set 1702 includesten rows, that the input data set 1702 includes two columns denoted Aand B, and that the models illustrated in FIG. 17 represent neuralnetworks that output a predicted a value of B given an input value of A.In this example, testing a model may include inputting each of the tenvalues of A from the input data set 1702, comparing the predicted valuesof B to the corresponding actual values of B from the input data set1702, and determining if and/or by how much the two predicted and actualvalues of B differ. To illustrate, if a particular neural networkcorrectly predicted the value of B for nine of the ten rows, then the arelatively simple fitness function 1740 may assign the correspondingmodel a fitness value of 9/10=0.9. It is to be understood that theprevious example is for illustration only and is not to be consideredlimiting. In some aspects, the fitness function 1740 may be based onfactors unrelated to error frequency or error rate, such as number ofinput nodes, node layers, hidden layers, connections, computationalcomplexity, etc.

In a particular aspect, fitness evaluation of models may be performed inparallel. To illustrate, the system 1700 may include additional devices,processors, cores, and/or threads 1790 to those that execute the geneticalgorithm 1710 and the backpropagation trainer 1780. These additionaldevices, processors, cores, and/or threads 1790 may test model fitnessin parallel based on the input data set 1702 and may provide theresulting fitness values to the genetic algorithm 1710.

In a particular aspect, the genetic algorithm 1710 may be configured toperform speciation. For example, the genetic algorithm 1710 may beconfigured to cluster the models of the input set 1720 into speciesbased on “genetic distance” between the models. Because each modelrepresents a neural network, the genetic distance between two models maybe based on differences in nodes, activation functions, aggregationfunctions, connections, connection weights, etc. of the two models. Inan illustrative example, the genetic algorithm 1710 may be configured toserialize a model into a bit string. In this example, the geneticdistance between models may be represented by the number of differingbits in the bit strings corresponding to the models. The bit stringscorresponding to models may be referred to as “encodings” of the models.Speciation is further described with reference to FIG. 19 .

Because the genetic algorithm 1710 is configured to mimic biologicalevolution and principles of natural selection, it may be possible for aspecies of models to become “extinct.” The stagnation criterion 1750 maybe used to determine when a species should become extinct, e.g., whenthe models in the species are to be removed from the genetic algorithm1710. Stagnation is further described with reference to FIG. 20 .

The crossover operation 1760 and the mutation operation 1770 are highlystochastic under certain constraints and a defined set of probabilitiesoptimized for model building, which produce reproduction operations thatcan be used to generate the output set 1730, or at least a portionthereof, from the input set 1720. In a particular aspect, the geneticalgorithm 1710 utilizes intra-species reproduction but not inter-speciesreproduction in generating the output set 1730. Including intra-speciesreproduction and excluding inter-species reproduction may be based onthe assumption that because they share more genetic traits, the modelsof a species are more likely to cooperate and will therefore morequickly converge on a sufficiently accurate neural network. In someexamples, inter-species reproduction may be used in addition to orinstead of intra-species reproduction to generate the output set 1730.Crossover and mutation are further described with reference to FIG. 22 .

Left alone and given time to execute enough epochs, the geneticalgorithm 1710 may be capable of generating a model (and by extension, aneural network) that meets desired accuracy requirements. However,because genetic algorithms utilize randomized selection, it may beoverly time-consuming for a genetic algorithm to arrive at an acceptableneural network. In accordance with the present disclosure, to “help” thegenetic algorithm 1710 arrive at a solution faster, a model mayoccasionally be sent from the genetic algorithm 1710 to thebackpropagation trainer 1780 for training. This model is referred toherein as a trainable model 1722. In particular, the trainable model1722 may be based on crossing over and/or mutating the fittest models ofthe input set 1720, as further described with reference to FIG. 22 .Thus, the trainable model 1722 may not merely be a genetically “trained”file produced by the genetic algorithm 1710. Rather, the trainable model1722 may represent an advancement with respect to the fittest models ofthe input set 1720.

The backpropagation trainer 1780 may utilize a portion, but not all ofthe input data set 1702 to train the connection weights of the trainablemodel 1722, thereby generating a trained model 1782. For example, theportion of the input data set 1702 may be input into the trainable model1722, which may in turn generate output data. The input data set 1702and the output data may be used to determine an error value, and theerror value may be used to modify connection weights of the model, suchas by using gradient descent or another function.

The backpropagation trainer 1780 may train using a portion rather thanall of the input data set 1702 to mitigate overfit concerns and/or toshorten training time. The backpropagation trainer 1780 may leaveaspects of the trainable model 1722 other than connection weights (e.g.,neural network topology, activation functions, etc.) unchanged.Backpropagating a portion of the input data set 1702 through thetrainable model 1722 may serve to positively reinforce “genetic traits”of the fittest models in the input set 1720 that were used to generatethe trainable model 1722. Because the backpropagation trainer 1780 maybe executed on a different device, processor, core, and/or thread thanthe genetic algorithm 1710, the genetic algorithm 1710 may continueexecuting additional epoch(s) while the connection weights of thetrainable model 1722 are being trained. When training is complete, thetrained model 1782 may be input back into (a subsequent epoch of) thegenetic algorithm 1710, so that the positively reinforced “genetictraits” of the trained model 1782 are available to be inherited by othermodels in the genetic algorithm 1710.

Operation of the system 1700 is now described with reference to FIGS.19-23 . It is to be understood, however, that in alternativeimplementations certain operations may be performed in a different orderthan described. Moreover, operations described as sequential may beinstead be performed at least partially concurrently, and operationsdescribed as being performed at least partially concurrently may insteadbe performed sequentially.

During a configuration stage of operation, a user or configuration filemay specify data sources from which the pre-processor 1704 is todetermine the input data set 1702. The user or configuration file mayalso specify a particular data field or a set of data fields in theinput data set 1702 to be modeled. The pre-processor 1704 may determinethe input data set 1702, determine a machine learning problem type to besolved, and initialize the AMB engine (e.g., the genetic algorithm 1710and/or the backpropagation trainer 1780) based on the input data set1702 and the machine learning problem type. As an illustrativenon-limiting example, the pre-processor 1704 may determine that the datafield(s) to be modeled corresponds to output nodes of a neural networkthat is to be generated by the system 1700. For example, if a user orconfiguration file indicates that the value of a particular data fieldis to be modeled (e.g., to predict the value based on other data of thedata set), the model may be generated by the system 1700 to include anoutput node that generates an output value corresponding to a modeledvalue of the particular data field. In particular implementations, theuser or configuration file can also configure other aspects of themodel. For example, the user or configuration file may provide input toindicate a particular data field of the data set that is to be includedin the model or a particular data field of the data set that is to beomitted from the model. As another example, the user or configurationfile may provide input to constrain allowed model topologies. Toillustrate, the model may be constrained to include no more than aspecified number of input nodes, no more than a specified number ofhidden layers, or no recurrent loops.

Further, in particular implementations, a user can configure aspects ofthe genetic algorithm 1710, such as via input to the pre-processor 1704or graphical user interfaces (GUIs) generated by the pre-processor 1704,or such aspects may be configured via a configuration file. The user mayprovide input to limit a number of epochs that will be executed by thegenetic algorithm 1710. Alternatively, the user may specify a time limitindicating an amount of time that the genetic algorithm 1710 has togenerate a “final” model, and the genetic algorithm 1710 may determine anumber of epochs that will be executed based on the specified timelimit. To illustrate, an initial epoch of the genetic algorithm 1710 maybe timed (e.g., using a hardware or software timer at the computingdevice executing the genetic algorithm 1710), and a total number ofepochs that are to be executed within the specified time limit may bedetermined accordingly. As another example, the user may constrain anumber of models evaluated in each epoch, for example by constrainingthe size of the input set 1720 and/or the output set 1730. As yetanother example, the user can define a number of trainable models 1722to be trained by the backpropagation trainer 1780 and fed back into thegenetic algorithm 1710 as trained models 1782.

In particular aspects, configuration of the genetic algorithm 1710 bythe pre-processor 1704 includes performing other pre-processing steps.For example, the pre-processor 1704 may determine whether a neuralnetwork is to be generated for a regression problem, a classificationproblem, a reinforcement learning problem, etc. As another example, theinput data set 1702 may be “cleaned” to remove obvious errors, fill indata “blanks,” etc. in the data source(s) from which the input data set1702 is generated. As another example, values in the input data set 1702may be scaled (e.g., to values between 0 and 1) relative to values inthe data source(s). As yet another example, non-numerical data (e.g.,categorical classification data or Boolean data) in the data source(s)may be converted into numerical data or some other form of data that iscompatible for ingestion and processing by a neural network. Thus, thepre-processor 1704 may serve as a “front end” that enables the same AMBengine to be driven by input data sources for multiple types ofcomputing problems, including but not limited to classificationproblems, regression problems, and reinforcement learning problems.

During automated model building, the genetic algorithm 1710 mayautomatically generate an initial set of models based on the input dataset 1702, received input indicating (or usable to determine) the type ofproblem to be solved, etc. (e.g., the initial set of models isdata-driven). As illustrated in FIG. 18 , each model may be specified byat least a neural network topology, an activation function, and linkweights. The neural network topology may indicate an arrangement ofnodes (e.g., neurons). For example, the neural network topology mayindicate a number of input nodes, a number of hidden layers, a number ofnodes per hidden layer, and a number of output nodes. The neural networktopology may also indicate the interconnections (e.g., axons or links)between nodes.

The initial set of models may be input into an initial epoch of thegenetic algorithm 1710 as the input set 1720, and at the end of theinitial epoch, the output set 1730 generated during the initial epochmay become the input set 1720 of the next epoch of the genetic algorithm1710. In some examples, the input set 1720 may have a specific number ofmodels. For example, as shown in a first stage 1900 of operation in FIG.19 , the input set may include 200 models. It is to be understood thatalternative examples may include a different number of models in theinput set 1720 and/or the output set 1730.

For the initial epoch of the genetic algorithm 1710, the topologies ofthe models in the input set 1720 may be randomly or pseudo-randomlygenerated within constraints specified by any previously inputconfiguration settings. Accordingly, the input set 1720 may includemodels with multiple distinct topologies. For example, a first model mayhave a first topology, including a first number of input nodesassociated with a first set of data parameters, a first number of hiddenlayers including a first number and arrangement of hidden nodes, one ormore output nodes, and a first set of interconnections between thenodes. In this example, a second model of epoch may have a secondtopology, including a second number of input nodes associated with asecond set of data parameters, a second number of hidden layersincluding a second number and arrangement of hidden nodes, one or moreoutput nodes, and a second set of interconnections between the nodes.Since the first model and the second model are both attempting to modelthe same data field(s), the first and second models have the same outputnodes.

The genetic algorithm 1710 may automatically assign an activationfunction, an aggregation function, a bias, connection weights, etc. toeach model of the input set 1720 for the initial epoch. In some aspects,the connection weights are assigned randomly or pseudo-randomly. In someimplementations, a single activation function is used for each node of aparticular model. For example, a sigmoid function may be used as theactivation function of each node of the particular model. The singleactivation function may be selected based on configuration data. Forexample, the configuration data may indicate that a hyperbolic tangentactivation function is to be used or that a sigmoid activation functionis to be used. Alternatively, the activation function may be randomly orpseudo-randomly selected from a set of allowed activation functions, anddifferent nodes of a model may have different types of activationfunctions. In other implementations, the activation function assigned toeach node may be randomly or pseudo-randomly selected (from the set ofallowed activation functions) for each node the particular model.Aggregation functions may similarly be randomly or pseudo-randomlyassigned for the models in the input set 1720 of the initial epoch.Thus, the models of the input set 1720 of the initial epoch may havedifferent topologies (which may include different input nodescorresponding to different input data fields if the data set includesmany data fields) and different connection weights. Further, the modelsof the input set 1720 of the initial epoch may include nodes havingdifferent activation functions, aggregation functions, and/or biasvalues/functions.

Continuing to a second stage 1950 of operation, each model of the inputset 1720 may be tested based on the input data set 1702 to determinemodel fitness. For example, the input data set 1702 may be provided asinput data to each model, which processes the input data set (accordingto the network topology, connection weights, activation function, etc.,of the respective model) to generate output data. The output data ofeach model may be evaluated using the fitness function 1740 to determinehow well the model modeled the input data set 1702. For example, in thecase of a regression problem, the output data may be evaluated bycomparing a prediction value in the output data to an actual value inthe input data set 1702. As another example, in the case of aclassification problem, a classifier result indicated by the output datamay be compared to a classification associated with the input data set1702 to determine if the classifier result matches the classification inthe input data set 1702. As yet another example, in the case of areinforcement learning problem, a reward may be determined (e.g.,calculated) based on evaluation of an environment, which may include oneor more variables, functions, etc. In a reinforcement learning problem,the fitness function 1740 may be the same as or may be based on thereward function(s). Fitness of a model may be evaluated based onperformance (e.g., accuracy) of the model, complexity (or sparsity) ofthe model, or a combination thereof. As a simple example, in the case ofa regression problem or reinforcement learning problem, a fitness valuemay be assigned to a particular model based on an error value associatedwith the output data of that model or based on the value of the rewardfunction, respectively. As another example, in the case of aclassification problem, the fitness value may be assigned based onwhether a classification determined by a particular model is a correctclassification, or how many correct or incorrect classifications weredetermined by the model.

In a more complex example, the fitness value may be assigned to aparticular model based on both prediction/classification accuracy orreward optimization as well as complexity (or sparsity) of the model. Asan illustrative example, a first model may model the data set well(e.g., may generate output data or an output classification with arelatively small error, or may generate a large positive reward functionvalue) using five input nodes (corresponding to five input data fields),whereas a second potential model may also model the data set well usingtwo input nodes (corresponding to two input data fields). In thisillustrative example, the second model may be sparser (depending on theconfiguration of hidden nodes of each network model) and therefore maybe assigned a higher fitness value that the first model.

As shown in FIG. 19 , the second stage 1950 may include clustering themodels into species based on genetic distance. In a particular aspect,the species ID 1830 of each of the models may be set to a valuecorresponding to the species that the model has been clustered into.

Continuing to FIG. 20 , during a third stage 2000 and a fourth stage2050 of operation, a species fitness may be determined for each of thespecies. The species fitness of a species may be a function of thefitness of one or more of the individual models in the species. As asimple illustrative example, the species fitness of a species may be theaverage of the fitness of the individual models in the species. Asanother example, the species fitness of a species may be equal to thefitness of the fittest or least fit individual model in the species. Inalternative examples, other mathematical functions may be used todetermine species fitness. The genetic algorithm 1710 may maintain adata structure that tracks the fitness of each species across multipleepochs. Based on the species fitness, the genetic algorithm 1710 mayidentify the “fittest” species, shaded and denoted in FIG. 20 as “elitespecies.” Although three elite species 2010, 2020, and 2030 are shown inFIG. 20 , it is to be understood that in alternate examples a differentnumber of elite species may be identified.

In a particular aspect, the genetic algorithm 1710 uses species fitnessto determine if a species has become stagnant and is therefore to becomeextinct. As an illustrative non-limiting example, the stagnationcriterion 1750 may indicate that a species has become stagnant if thefitness of that species remains within a particular range (e.g., +/−6%)for a particular number (e.g., 6) epochs. If a species satisfiesstagnation criteria, the species and all underlying models may beremoved from the genetic algorithm 1710. In the illustrated example,species 1960 of FIG. 19 is removed, as shown in the third stage 2000through the use of broken lines.

Proceeding to the fourth stage 2050, the fittest models of each “elitespecies” may be identified. The fittest models overall may also beidentified. In the illustrated example, the three fittest models of each“elite species” are denoted “elite members” and shown using a hatchpattern. Thus, model 2070 is an “elite member” of the “elite species”2060. The three fittest models overall are denoted “overall elites” andare shown using black circles. Thus, models 2060, 2062, and 2064 are the“overall elites” in the illustrated example. As shown in FIG. 20 withrespect to the model 2060, an “overall elite” need not be an “elitemember,” e.g., may come from a non-elite species. In an alternateimplementation, a different number of “elite members” per species and/ora different number of “overall elites” may be identified.

Referring now to FIG. 21 during a fifth stage 2100 of operation, the“overall elite” models 2060, 2062, and 2064 may be genetically combinedto generate the trainable model 1722. For example, genetically combiningmodels may include crossover operations in which a portion of one modelis added to a portion of another model, as further illustrated in FIG.22 . As another example, a random mutation may be performed on a portionof one or more of the “overall elite” models 2060, 2062, 2064 and/or thetrainable model 1722. The trainable model 1722 may be sent to thebackpropagation trainer 1780, as described with reference to FIG. 17 .The backpropagation trainer 1780 may train connection weights of thetrainable model 1722 based on a portion of the input data set 1702. Whentraining is complete, the resulting trained model 1782 may be receivedfrom the backpropagation trainer 1780 and may be input into a subsequentepoch of the genetic algorithm 1710.

Continuing to FIG. 22 , while the backpropagation trainer 1780 trainsthe trainable model, the output set 1730 of the epoch may be generatedin a sixth stage 2200 of operation. In the illustrated example, theoutput set 1730 includes the same number of models, e.g., 200 models, asthe input set 1720. The output set 1730 may include each of the “overallelite” models 2060-2064. The output set 1730 may also include each ofthe “elite member” models, including the model 2070. Propagating the“overall elite” and “elite member” models to the next epoch may preservethe “genetic traits” that resulted in such models being assigned highfitness values.

The rest of the output set 1730 may be filled out by randomintra-species reproduction using the crossover operation 1760 and/or themutation operation 1770. In the illustrated example, the output set 1730includes 10 “overall elite” and “elite member” models, so the remainingmodels may be randomly generated based on intra-species reproductionusing the crossover operation 1760 and/or the mutation operation 1770.After the output set 1730 is generated, the output set 1730 may beprovided as the input set 1720 for the next epoch of the geneticalgorithm 1710.

During the crossover operation 1760, a portion of one model may becombined with a portion of another model, where the size of therespective portions may or may not be equal. To illustrate withreference to the model “encodings” described with respect to FIG. 17 ,the crossover operation 1760 may include concatenating bits 0 to p ofone bit string with bits p+1 to q of another bit string, where p and qare integers and p+q is equal to the total size of a bit string thatrepresents a model resulting from the crossover operation 1760. Whendecoded, the resulting bit string after the crossover operation 1760produces a neural network that differs from each of its “parent” neuralnetworks in terms of topology, activation function(s), aggregationfunction(s), bias value(s)/function(s), link weight(s), or anycombination thereof.

Thus, the crossover operation 1760 may be a random or pseudo-randombiological operator that generates a model of the output set 1730 bycombining aspects of a first model of the input set 1720 with aspects ofone or more other models of the input set 1720. For example, thecrossover operation 1760 may retain a topology of hidden nodes of afirst model of the input set 1720 but connect input nodes of a secondmodel of the input set to the hidden nodes. As another example, thecrossover operation 1760 may retain the topology of the first model ofthe input set 1720 but use one or more activation functions of thesecond model of the input set 1720. In some aspects, rather thanoperating on models of the input set 1720, the crossover operation 1760may be performed on a model (or models) generated by mutation of one ormore models of the input set 1720. For example, the mutation operation1770 may be performed on a first model of the input set 1720 to generatean intermediate model and the crossover operation 1760 may be performedto combine aspects of the intermediate model with aspects of a secondmodel of the input set 1720 to generate a model of the output set 1730.

During the mutation operation 1770, a portion of a model may be randomlymodified. The frequency of mutations may be based on a mutationprobability metric, which may be user-defined or randomlyselected/adjusted. To illustrate with reference to the model “encodings”described with respect to FIG. 17 , the mutation operation 1770 mayinclude randomly “flipping” one or more bits a bit string.

The mutation operation 1770 may thus be a random or pseudo-randombiological operator that generates or contributes to a model of theoutput set 1730 by mutating any aspect of a model of the input set 1720.For example, the mutation operation 1770 may cause the topology aparticular model of the input set to be modified by addition or omissionof one or more input nodes, by addition or omission of one or moreconnections, by addition or omission of one or more hidden nodes, or acombination thereof. As another example, the mutation operation 1770 maycause one or more activation functions, aggregation functions, biasvalues/functions, and/or or connection weights to be modified. In someaspects, rather than operating on a model of the input set, the mutationoperation 1770 may be performed on a model generated by the crossoveroperation 1760. For example, the crossover operation 1760 may combineaspects of two models of the input set 1720 to generate an intermediatemodel and the mutation operation 1770 may be performed on theintermediate model to generate a model of the output set 1730.

The genetic algorithm 1710 may continue in the manner described abovethrough multiple epochs. When the genetic algorithm 1710 receives thetrained model 1782, the trained model 1782 may be provided as part ofthe input set 1720 of the next epoch, as shown in a seventh stage 2300of FIG. 23 . For example, the trained model 1782 may replace one of theother 200 models in the input set 1720 or may be a 201st model of theinput set (e.g., in some epochs, more than 200 models may be processed).During training by the backpropagation trainer 1780, the geneticalgorithm 1710 may have advanced one or more epochs. Thus, when thetrained model 1782 is received, the trained model 1782 may be insertedas input into an epoch subsequent to the epoch during which thecorresponding trainable model 1722 was provided to the backpropagationtrainer 1780. To illustrate, if the trainable model 1722 was provided tothe backpropagation trainer 1780 during epoch N, then the trained model1782 may be input into epoch N+X, where X is an integer greater thanzero.

In the example of FIGS. 17 and 23 , a single trainable model 1722 isprovided to the backpropagation trainer 1780 and a single trained model1782 is received from the backpropagation trainer 1780. When the trainedmodel 1782 is received, the backpropagation trainer 1780 becomesavailable to train another trainable model. Thus, because training takesmore than one epoch, trained models 1782 may be input into the geneticalgorithm 1710 sporadically rather than every epoch after the initialepoch. In some implementations, the backpropagation trainer 1780 mayhave a queue or stack of trainable models 1722 that are awaitingtraining. The genetic algorithm 1710 may add trainable models 1722 tothe queue or stack as they are generated and the backpropagation trainer1780 may remove a trainable model 1722 from the queue or stack at thestart of a training cycle. In some implementations, the system 1700includes multiple backpropagation trainers 1780 (e.g., executing ondifferent devices, processors, cores, or threads). Each of thebackpropagation trainers 1780 may be configured to simultaneously traina different trainable model 1722 to generate a different trained model1782. In such examples, more than one trainable model 1722 may begenerated during an epoch and/or more than one trained model 1782 may beinput into an epoch.

Operation at the system 1700 may continue iteratively until specified atermination criterion, such as a time limit, a number of epochs, or athreshold fitness value (of an overall fittest model) is satisfied. Whenthe termination criterion is satisfied, an overall fittest model of thelast executed epoch may be selected and output as representing a neuralnetwork that best models the input data set 1702. In some examples, theoverall fittest model may undergo a final training operation (e.g., bythe backpropagation trainer 1780) before being output.

Although various aspects are described with reference to abackpropagation training, it is to be understood that in alternateimplementations different types of training may also be used in thesystem 1700. For example, models may be trained using a geneticalgorithm training process. In this example, genetic operations similarto those described above are performed while all aspects of a model,except for the connection weight, are held constant.

Performing genetic operations may be less resource intensive thanevaluating fitness of models and training of models usingbackpropagation. For example, both evaluating the fitness of a model andtraining a model include providing the input data set 1702, or at leasta portion thereof, to the model, calculating results of nodes andconnections of a neural network to generate output data, and comparingthe output data to the input data set 1702 to determine the presenceand/or magnitude of an error. In contrast, genetic operations do notoperate on the input data set 1702, but rather merely modifycharacteristics of one or more models. However, as described above, oneiteration of the genetic algorithm 1710 may include both geneticoperations and evaluating the fitness of every model and species.Training trainable models generated by breeding the fittest models of anepoch may improve fitness of the trained models without requiringtraining of every model of an epoch. Further, the fitness of models ofsubsequent epochs may benefit from the improved fitness of the trainedmodels due to genetic operations based on the trained models.Accordingly, training the fittest models enables generating a model witha particular error rate in fewer epochs than using genetic operationsalone. As a result, fewer processing resources may be utilized inbuilding highly accurate models based on a specified input data set1702.

The system 1700 of FIG. 17 may thus support cooperative, data-drivenexecution of a genetic algorithm and a backpropagation trainer toautomatically arrive at an output neural network model of an input dataset. The system of FIG. 17 may arrive at the output neural network modelfaster than using a genetic algorithm or backpropagation alone and withreduced cost as compared to hiring a data scientist. In some cases, theneural network model output by the system 1700 may also be more accuratethan a model that would be generated by a genetic algorithm orbackpropagation alone. The system 1700 may also provide aproblem-agnostic ability to generate neural networks. For example, thesystem 1700 may represent a single automated model building frameworkthat is capable of generating neural networks for at least regressionproblems, classification problems, and reinforcement learning problems.Further, the system 1700 may enable generation of a generalized neuralnetwork that demonstrates improved adaptability to never-before-seenconditions. To illustrate, the neural network may mitigate or avoidoverfitting to an input data set and instead may be more universal innature. Thus, the neural networks generated by the system 1700 may becapable of being deployed with fewer concerns about generating incorrectpredictions.

FIG. 24 is a block diagram of a particular computer system 2400configured to initiate, perform, or control one or more of theoperations described with reference to FIGS. 1-23 . For example, thecomputer system 2400 may include, or be included within, one or more ofthe devices, wide area wireless networks, or servers described withreference to FIGS. 1-23 . The computer system 2400 can also beimplemented as or incorporated into one or more of various otherdevices, such as a personal computer (PC), a tablet PC, a servercomputer, a personal digital assistant (PDA), a laptop computer, adesktop computer, a communications device, a wireless telephone, or anyother machine capable of executing a set of instructions (sequential orotherwise) that specify actions to be taken by that machine. In someexamples, the computer system 2400, or at least components thereof, areincluded in a device that is associated with a battery or a cell, suchas a vehicle, a device associated with a battery-based electrical grid,etc. Further, while a single computer system 2400 is illustrated, theterm “system” includes any collection of systems or sub-systems thatindividually or jointly execute a set, or multiple sets, of instructionsto perform one or more computer functions.

While FIG. 24 illustrates one example of the particular computer system2400, other computer systems or computing architectures andconfigurations may be used for carrying out the operations disclosedherein. The computer system 2400 includes one or more processors 2402.Each processor of the one or more processors 2402 can include a singleprocessing core or multiple processing cores that operate sequentially,in parallel, or sequentially at times and in parallel at other times.Each processor of the one or more processors 2402 includes circuitrydefining a plurality of logic circuits 2404, working memory 2406 (e.g.,registers and cache memory), communication circuits, etc., whichtogether enable the processor to control the operations performed by thecomputer system 2400 and enable the processor to generate a usefulresult based on analysis of particular data and execution of specificinstructions.

The processor(s) 2402 are configured to interact with other componentsor subsystems of the computer system 2400 via a bus 2460. The bus 2460is illustrative of any interconnection scheme serving to link thesubsystems of the computer system 2400, external subsystems or device,or any combination thereof. The bus 2460 includes a plurality ofconductors to facilitate communication of electrical and/orelectromagnetic signals between the components or subsystems of thecomputer system 2400. Additionally, the bus 2460 includes one or morebus controller or other circuits (e.g., transmitters and receivers) thatmanage signaling via the plurality of conductors and that cause signalssent the plurality of conductors to conform to particular communicationprotocols.

The computer system 2400 also includes one or more memory devices 2410.The memory devices 2410 include any suitable computer-readable storagedevice depending on, for example, whether data access needs to bebi-directional or unidirectional, speed of data access required, memorycapacity required, other factors related to data access, or anycombination thereof. Generally, the memory devices 2410 include somecombination of volatile memory devices and non-volatile memory devices,though in some implementations, only one or the other may be present.Examples of volatile memory devices and circuits include registers,caches, latches, many types of random-access memory (RAM), such asdynamic random-access memory (DRAM), etc. Examples of non-volatilememory devices and circuits include hard disks, optical disks, flashmemory, and certain type of RAM, such as resistive random-access memory(ReRAM). Other examples of both volatile and non-volatile memory devicescan be used as well, or in the alternative, so long as such memorydevices store information in a physical, tangible medium. Thus, thememory devices 2410 include circuit and structures and are not merelysignals or other transitory phenomena.

The memory device(s) 2410 store instructions 2412 that are executable bythe processor(s) 2402 to perform various operations and functions. Theinstructions 2412 include instructions to enable the various componentsand subsystems of the computer system 2400 to operate, interact with oneanother, and interact with a user, such as an input/output system (BIOS)2414 and an operating system (OS) 2416. Additionally, the instructions2412 include one or more applications 2418, scripts, or other programcode to enable the processor(s) 2402 to perform the operations describedherein. For example, the instructions 2412 can include the modelgenerator 2560 of FIG. 13 .

In FIG. 24 , the computer system 2400 also includes one or more outputdevices 2430, one or more input devices 2420, and one or more networkinterface devices 2440. Each of the output device(s) 2430, the inputdevice(s) 2420, and the network interface device(s) 2440 can be coupledto the bus 2460 via an a port or connector, such as a Universal SerialBus port, a digital visual interface (DVI) port, a serial ATA (SATA)port, a small computer system interface (SCSI) port, a high-definitionmedia interface (HMDI) port, or another serial or parallel port. In someimplementations, one or more of the output device(s) 2430, the inputdevice(s) 2420, the network interface device(s) 2440 is coupled to orintegrated within a housing with the processor(s) 2402 and the memorydevices 2410, in which case the connections to the bus 2460 can beinternal, such as via an expansion slot or other card-to-card connector.In other implementations, the processor(s) 2402 and the memory devices2410 are integrated within a housing that includes one or more externalports, and one or more of the output device(s) 2430, the input device(s)2420, the network interface device(s) 2440 is coupled to the bus 2460via the external port(s).

Examples of the output device(s) 2430 include a display device, one ormore speakers, a printer, a television, a projector, or another deviceto provide an output of data in a manner that is perceptible by a user.Examples of the input device(s) 2420 include buttons, switches, knobs, akeyboard 2422, a pointing device 2424, a biometric device, a microphone,a motion sensor, or another device to detect user input actions. Thepointing device 2424 includes, for example, one or more of a mouse, astylus, a track ball, a pen, a touch pad, a touch screen, a tablet,another device that is useful for interacting with a graphical userinterface, or any combination thereof.

The network interface device(s) 2440 is configured to enable thecomputer system 2400 to communicate with one or more other computersystems 2444 via one or more networks 2442. The network interfacedevice(s) 2440 encode data in electrical and/or electromagnetic signalsthat are transmitted to the other computer system(s) 2444 usingpre-defined communication protocols. The electrical and/orelectromagnetic signals can be transmitted wirelessly (e.g., viapropagation through free space), via one or more wires, cables, opticalfibers, or via a combination of wired and wireless transmission.

In an alternative embodiment, dedicated hardware implementations, suchas application specific integrated circuits, programmable logic arraysand other hardware devices, can be constructed to implement one or moreof the operations described herein. Accordingly, the present disclosureencompasses software, firmware, and hardware implementations.

It is to be understood that the division and ordering of steps describedherein is for illustrative purposes only and is not be consideredlimiting. In alternative implementations, certain steps may be combinedand other steps may be subdivided into multiple steps. Moreover, theordering of steps may change.

The systems and methods illustrated herein may be described in terms offunctional block components, screen shots, optional selections andvarious processing steps. It should be appreciated that such functionalblocks may be realized by any number of hardware and/or softwarecomponents configured to perform the specified functions. For example,the system may employ various integrated circuit components, e.g.,memory elements, processing elements, logic elements, look-up tables,and the like, which may carry out a variety of functions under thecontrol of one or more microprocessors or other control devices.Similarly, the software elements of the system may be implemented withany programming or scripting language such as C, C++, C #, Java,JavaScript, VBScript, Macromedia Cold Fusion, COBOL, Microsoft ActiveServer Pages, assembly, PERL, PHP, AWK, Python, Visual Basic, SQL StoredProcedures, PL/SQL, any UNIX shell script, and extensible markuplanguage (XML) with the various algorithms being implemented with anycombination of data structures, objects, processes, routines or otherprogramming elements. Further, it should be noted that the system mayemploy any number of techniques for data transmission, signaling, dataprocessing, network control, and the like.

The systems and methods of the present disclosure may be embodied as acustomization of an existing system, an add-on product, a processingapparatus executing upgraded software, a standalone system, adistributed system, a method, a data processing system, a device fordata processing, and/or a computer program product. Accordingly, anyportion of the system or a module may take the form of a processingapparatus executing code, an internet based (e.g., cloud computing)embodiment, an entirely hardware embodiment, or an embodiment combiningaspects of the internet, software and hardware. Furthermore, the systemmay take the form of a computer program product on a computer-readablestorage medium or device having computer-readable program code (e.g.,instructions) embodied or stored in the storage medium or device. Anysuitable computer-readable storage medium or device may be utilized,including hard disks, CD-ROM, optical storage devices, magnetic storagedevices, and/or other storage media. As used herein, a“computer-readable storage medium” or “computer-readable storage device”is not a signal.

Computer program instructions may be loaded onto a computer or otherprogrammable data processing apparatus to produce a machine, such thatthe instructions that execute on the computer or other programmable dataprocessing apparatus create means for implementing the functionsspecified in the flowchart block or blocks. These computer programinstructions may also be stored in a computer-readable memory or devicethat can direct a computer or other programmable data processingapparatus to function in a particular manner, such that the instructionsstored in the computer-readable memory produce an article of manufactureincluding instruction means which implement the function specified inthe flowchart block or blocks. The computer program instructions mayalso be loaded onto a computer or other programmable data processingapparatus to cause a series of operational steps to be performed on thecomputer or other programmable apparatus to produce acomputer-implemented process such that the instructions which execute onthe computer or other programmable apparatus provide steps forimplementing the functions specified in the flowchart block or blocks.

Accordingly, functional blocks of the block diagrams and flowchartillustrations support combinations of means for performing the specifiedfunctions, combinations of steps for performing the specified functions,and program instruction means for performing the specified functions. Itwill also be understood that each functional block of the block diagramsand flowchart illustrations, and combinations of functional blocks inthe block diagrams and flowchart illustrations, can be implemented byeither special purpose hardware-based computer systems which perform thespecified functions or steps, or suitable combinations of specialpurpose hardware and computer instructions.

Although the disclosure may include a method, it is contemplated that itmay be embodied as computer program instructions on a tangiblecomputer-readable medium, such as a magnetic or optical memory or amagnetic or optical disk/disc. All structural, chemical, and functionalequivalents to the elements of the above-described exemplary embodimentsthat are known to those of ordinary skill in the art are expresslyincorporated herein by reference and are intended to be encompassed bythe present claims. Moreover, it is not necessary for a device or methodto address each and every problem sought to be solved by the presentdisclosure, for it to be encompassed by the present claims. Furthermore,no element, component, or method step in the present disclosure isintended to be dedicated to the public regardless of whether theelement, component, or method step is explicitly recited in the claims.

Changes and modifications may be made to the disclosed embodimentswithout departing from the scope of the present disclosure. These andother changes or modifications are intended to be included within thescope of the present disclosure, as expressed in the following claims.

What is claimed is:
 1. A method comprising: obtaining, by a processor,battery characterization data based on sensor data from one or moresensors onboard a vehicle; providing, by the processor, the batterycharacterization data as input to a trained model to generate a modeloutput; and altering a vehicle operating parameter based on the modeloutput.
 2. The method of claim 1, further comprising identifying thebattery characterization data with a driver type profile.
 3. The methodof claim 1, wherein the sensor data is captured during a time periodthat includes multiple discharging operations and multiple rechargingoperations of a battery of the vehicle.
 4. The method of claim 1,wherein the one or more sensors include battery sensors that identifyphysical characteristics of a battery of the vehicle.
 5. The method ofclaim 1, wherein the one or more sensors include non-battery sensorsthat identify physical characteristics of components of the vehicleother than a battery.
 6. The method of claim 1, wherein the vehicleoperating parameter includes a throttle responsiveness parameter.
 7. Themethod of claim 1, wherein the vehicle operating parameter includes alength of time that gears are held.
 8. The method of claim 1, whereinthe vehicle operating parameter includes an engine rotations per minuteparameter.
 9. The method of claim 1, wherein the vehicle operatingparameter includes a traction control system parameter.
 10. The methodof claim 1, further comprising, prior to altering the vehicle operatingparameter, determining a current operation of the vehicle, wherein thevehicle operating parameter is not changed responsive to determiningthat the vehicle is in motion.
 11. The method of claim 1, wherein thevehicle operating parameter is altered responsive to the model outputindicating that a battery has a particular charge.
 12. The method ofclaim 1, wherein the vehicle operating parameter is altered responsiveto the model output indicating that a battery has a particular healthprofile.
 13. A system comprising: one or more processors; and one ormore memory devices coupled to the one or more processors, the one ormore memory devices storing instructions that are executable to causethe one or more processors to perform operations comprising: obtainingbattery characterization data based on sensor data from one or moresensors onboard a vehicle; providing the battery characterization dataas input to a trained model to generate a model output; and altering avehicle operating parameter based on the model output.
 14. The system ofclaim 13, further comprising identifying the battery characterizationdata with a driver type profile.
 15. The system of claim 13, wherein thesensor data is captured during a time period that includes multipledischarging operations and multiple recharging operations of a batteryof the vehicle.
 16. The system of claim 13, wherein the one or moresensors include battery sensors that identify physical characteristicsof a battery of the vehicle.
 17. The system of claim 13, wherein the oneor more sensors include non-battery sensors that identify physicalcharacteristics of components of the vehicle other than a battery. 18.The system of claim 13, wherein the vehicle operating parameter includesa throttle responsiveness parameter.
 19. A computer-readable storagedevice storing instructions that, when executed by one or moreprocessors, cause the processors to: obtain battery characterizationdata based on sensor data from one or more sensors onboard a vehicle;provide the battery characterization data as input to a trained model togenerate a model output; and alter a vehicle operating parameter basedon the model output.
 20. The computer-readable storage device of claim19, wherein the vehicle operating parameter includes a throttleresponsiveness parameter.